On Mon, Aug 12, 2024 at 4:57 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Mon, Aug 12, 2024 at 9:09 AM Jann Horn <jannh@xxxxxxxxxx> wrote: > > On Mon, Aug 12, 2024 at 12:04 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > ... > > > > From a LSM perspective I suspect we are always going to need some sort > > > of hook in the F_SETOWN code path as the LSM needs to potentially > > > capture state/attributes/something-LSM-specific at that > > > context/point-in-time. > > > > The only thing LSMs currently do there is capture state from > > current->cred. So if the VFS takes care of capturing current->cred > > there, we should be able to rip out all the file_set_fowner stuff. > > Something like this (totally untested): > > I've very hesitant to drop the LSM hook from the F_SETOWN path both > because it is reasonable that other LSMs may want to do other things > here, What is an example for other things an LSM might want to do there? As far as I understand, the whole point of this hook is to record the identity of the sender of signals - are you talking about an LSM that might not be storing credentials in struct cred, or something like that? > and adding a LSM hook to the kernel, even if it is re-adding a > hook that was previously removed, is a difficult and painful process > with an uncertain outcome. Do you mean that even if the LSM hook ends up with zero users remaining, you'd still want to keep it around in case it's needed again later?
