Re: fanotify - overall design before I start sending patches

[Jamie Lokier]

Eric Paris wrote:
> But maybe I should jsut do the 'if you have fanotify open, you don't
> create other fanotify events'...   so everyone gets what they expect...

O_NONOTIFY.  Similar security concerns, more control.

The security concern is clear: If you allow a process with fanotify
open to not create events, then any (root) process can open a fanotify
socket to hide it's behaviour.

> >    - No file name for things that happen in a subdirectory.
> 
> Actually I should be more clear about that.  If you call
> setsockopt(FANOTIFY_ADD_MARK) where
> 
> struct fanotify_so_inode_mark {
>         __s32 fd;	= "/tmp/"
>         __u32 mask;	= (FAN_OPEN | FAN_EVENT_ON_CHILD);
>         __u32 ignored_mask; = 0
> };
> 
> and someone opens /tmp/file1 you are going to get an open fd
> for /tmp/file1 NOT for /tmp.  This is different than inotify.

If you inotify for IN_OPEN on /tmp, it would return an event when you
open /tmp/file1, with the name "file1" and the directory /tmp.  It's
no so different.  The main difference is inotify returns a name and no
inode number (so it's racy, sigh), whereas fanotify returns an open file.

Do I see right that you need to open the directory before you can set
the mark on it?

The main reason behind inotify's design wasn't the API (although it is
better than dnotify); it was to avoid having to open thousands of
directories, and to allow a filesystem to be unmounted while it is
being watched.

Does a fanotify mark stop a filesystem from being unmounted?  If not,
if the filesystem is unmounted and remounted, is the mark lost?

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/