Messages in this thread | | | From | David Howells <> | Subject | Re: What do LSMs *actually* need for checks on notifications? | Date | Wed, 12 Jun 2019 12:43:06 +0100 |
| |
Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > (6) The security attributes of all the objects between the object in (5) > > and the object in (4), assuming we work from (5) towards (4) if the > > two aren't coincident (WATCH_INFO_RECURSIVE). > > Does this apply to anything other than mount notifications?
Not at the moment. I'm considering making it such that you can make a watch on a keyring get automatically propagated to keys that get added to the keyring (and removed upon unlink) - the idea being that there is no 'single parent path' concept for a keyring as there is for a directory.
I'm also pondering the idea of making it possible to have superblock watches automatically propagated to superblocks created by automount points on the watched superblock.
> And for mount notifications, isn't the notification actually for a change to > the mount namespace, not a change to any file?
Yes.
> Hence, the real "object" for events that trigger mount notifications is the > mount namespace, right?
Um... arguably. Would that mean that that would need a label from somewhere?
> The watched path is just a way of identifying a subtree of the mount > namespace for notifications - it isn't the real object being watched.
I like that argument.
Thanks, David
| |