Re: [PATCH v2 0/2] unprivileged fanotify listener

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Well there is another way.
> > It is demonstrated in my demo with intoifywatch --fanotify --recursive.
> > It involved userspace iterating a subtree of interest to create fid->path
> > map.
>
> Ok, so this seems to be
>
> inotifytools_filename_from_fid()
> -> if (fanotify_mark_type != FAN_MARK_FILESYSTEM)
>            watch_from_fid()
>    -> read_path_from(/proc/self/fd/w->dirfd)
>

Yes.

> >
> > The fanotify recursive watch is similar but not exactly the same as the
> > old intoify recursive watch, because with inotify recursive watch you
> > can miss events.
> >
> > With fanotify recursive watch, the listener (if capable) can setup a
> > filesystem mark so events will not be missed. They will be recorded
> > by fid with an unknown path and the path information can be found later
> > by the crawler and updated in the map before the final report.
> >
> > Events on fid that were not found by the crawler need not be reported.
> > That's essentially a subtree watch for the poor implemented in userspace.
>
> This is already a good improvement.
> Honestly, having FAN_MARK_INODE workable unprivileged is already pretty

I'm not so sure why you say that, because unprivileged FAN_MARK_INODE
watches are pretty close in functionality to inotify.
There are only subtle differences.

> great. In addition having FAN_MARK_MOUNT workable with idmapped mounts
> will likely get us what most users care about, afaict that is the POC
> in:
> https://github.com/amir73il/linux/commit/f0d5d462c5baeb82a658944c6df80704434f09a1
>

Hmm, the problem is the limited set of events you can get from
FAN_MARK_MOUNT which does not include FAN_CREATE.

> (I'm reading the source correctly that FAN_MARK_MOUNT works with
> FAN_REPORT_FID as long as no inode event set in FANOTIFY_INODE_EVENTS is
> set? I'm asking because my manpage - probably too old - seems to imply
> that FAN_REPORT_FID can't be used with FAN_MARK_MOUNT although I might
> just be stumbling over the phrasing.)
>

commit d71c9b4a5c6fbc7164007b52dba1de410d018292
Author: Amir Goldstein <amir73il@xxxxxxxxx>
Date:   Mon Apr 20 21:42:56 2020 +0300

    fanotify_mark.2: Clarification about FAN_MARK_MOUNT and FAN_REPORT_FID

    It is not true that FAN_MARK_MOUNT cannot be used with a group
    that was initialized with flag FAN_REPORT_FID.
 ...

IOW, no FAN_CREATE, FAN_DELETE, FAN_MOVE

The technical reason for that is Al's objection to pass the mnt context
into vfs helpers (and then fsnotify hooks).

> I think FAN_MARK_FILESYSTEM should simply stay under the s_userns_s
> capable requirement. That's imho the cleanest semantics for this, i.e.
> I'd drop:
> https://github.com/amir73il/linux/commit/bd20e273f3c3a650805b3da32e493f01cc2a4763
> This is neither an urgent use-case nor am I feeling very comfortable
> with it.
>

The purpose of this commit is to provide FAN_CREATE, FAN_DELETE
FAN_MOVE events filtered by (an idmapped) mount.
I don't like it so much myself, but I have not had any better idea how to
achieve that goal so far.

There is another way though.
We can create a new set of hooks outside the vfs helpers that do have
the mnt context.

I have already created such a set for another POC [1].
In this POC I introduced three new events FS_MODIFY_INTENT,
FS_NAME_INTENT, FS_MOVE_INTENT, which I had no plans of
exposing to fanotify. Nor did I need the granularity of CREATE,
DELETE, RENAME event types (all collapsed into NAME_INTENT).

But if we hit a dead end, we can resort to this strategy.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fsnotify_pre_modify



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux