Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > Here's a set of patches to add a general variable-length notification queue > > concept and to add sources of events for: > > I asked before and didn't see a response, so I'll ask again. Why are you > paying any attention at all to the creds that generate an event? Casey responded to you. It's one of his requirements. I'm not sure of the need, and I particularly don't like trying to make indirect destruction events (mount destruction keyed on fput, for instance) carry the creds of the triggerer. Indeed, the trigger can come from all sorts of places - including af_unix queue destruction, someone poking around in procfs, a variety of processes fputting simultaneously. Only one of them can win, and the LSM needs to handle *all* the possibilities. However, the LSMs (or at least SELinux) ignore f_cred and use current_cred() when checking permissions. See selinux_revalidate_file_permission() for example - it uses current_cred() not file->f_cred to re-evaluate the perms, and the fd might be shared between a number of processes with different creds. > This seems like the wrong approach. If an LSM wants to prevent covert > communication from, say, mount actions, then it shouldn't allow the > watch to be set up in the first place. Yeah, I can agree to that. Casey? David
