On 1/16/2024 9:33 AM, Al Viro wrote: > On Tue, Jan 16, 2024 at 08:51:11AM -0800, Casey Schaufler wrote: >> On 1/16/2024 12:47 AM, Roberto Sassu wrote: >>> On Mon, 2024-01-15 at 19:15 +0000, Al Viro wrote: >>>> On Mon, Jan 15, 2024 at 07:17:57PM +0100, Roberto Sassu wrote: >>>>> From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> >>>>> >>>>> In preparation for moving IMA and EVM to the LSM infrastructure, introduce >>>>> the file_release hook. >>>>> >>>>> IMA calculates at file close the new digest of the file content and writes >>>>> it to security.ima, so that appraisal at next file access succeeds. >>>>> >>>>> An LSM could implement an exclusive access scheme for files, only allowing >>>>> access to files that have no references. >>>> Elaborate that last part, please. >>> Apologies, I didn't understand that either. Casey? >> Just a hypothetical notion that if an LSM wanted to implement an >> exclusive access scheme it might find the proposed hook helpful. >> I don't have any plan to create such a scheme, nor do I think that >> a file_release hook would be the only thing you'd need. > Exclusive access to what? "No more than one opened file with this > inode at a time"? It won't serialize IO operations, obviously... > Details, please. Once a file is opened it can't be opened again until it is closed. That's the simple description, which ignores all sorts of cases. I wouldn't want my system to behave that way, but I have heard arguments that multiple concurrent opens can be a security issue. In the context of my review of the code in question I included the comment solely for the purpose of acknowledging the potential for additional uses of the proposed hook. It's entirely possible someone (not me!) would use the hook in this or some other "clever" way.
