[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-api
Subject:    Re: [PATCH v2 0/2] unprivileged fanotify listener
From:       Amir Goldstein <amir73il () gmail ! com>
Date:       2021-03-28 14:58:09
Message-ID: CAOQ4uxje-zV2nWGa9juWUBzW29dgZBTnJR=jWGxjAJ4haiYTog () mail ! gmail ! com
[Download RAW message or body]

> > The limitations of FAN_MARK_MOUNT as I now understand them are indeed
> > unpleasant. If we could get FAN_MARK_MOUNT with the same event support
> > as FAN_MARK_INODE that would be great.
> > I think the delegation model that makes sense to me is to allow
> > FAN_MARK_MOUNT when the caller is ns_capable(mnt->mnt_userns) and of
> > course ns_capable() in the userns they called fanotify_init() in. That
> > feels ok and supportable.
>
> I present to you a demo [1][2] of FAN_MARK_MOUNT on idmapped mount that:
>
> 1. Can subscribe and receive FAN_LINK (new) events
> 2. Is capable of open_by_handle() if fid is under mount root
>
> FAN_LINK (temp name) is an event that I wanted to add anyway [3] and
> AFAIK it's the only event that you really need in order to detect when a dir
> was created for the use case of injecting a bind mount into a container.

Scratch that part about the new event.
I found a way to make FAN_CREATE available for FAN_MARK_MOUNT.
Will post an RFC patch.
Same demo instructions. Different branches [1][2]:

>
> The kernel branch [1] intentionally excludes the controversial patch that
> added support for userns filtered sb marks.
>
> Therefore, trying to run the demo script as is on an idmapped mount
> inside userns will auto-detect UID 0, try to setup an sb mark and fail.
>
> Instead, the demo script should be run as follows to combine a
> mount mark and recursive inode marks:
>
> ./test_demo.sh <idmapped-mount-path> 1
>
> For example:

~# ./test_demo.sh /vdf 1
+ WD=/vdf
+ ID=1
...
+ inotifywatch --fanotify --recursive -w --timeout -2 /vdf
Establishing watches...
...
+ mkdir -p a/dir0 a/dir1 a/dir2/A/B/C/
+ touch a/dir2/A/B/C/file2
...
[fid=94847cf7.d74a50ab.30000c2;name='dir2'] /mnt/a/dir2
Adding recursive watches on directory '/mnt/a/dir2/'...
[fid=94847cf7.d74a50ab.87;name='A'] /mnt/a/dir2/A
Adding recursive watches on directory '/mnt/a/dir2/A/'...
[fid=94847cf7.d74a50ab.1000087;name='B'] /mnt/a/dir2/A/B
Adding recursive watches on directory '/mnt/a/dir2/A/B/'...
[fid=94847cf7.d74a50ab.20073e5;name='C'] /mnt/a/dir2/A/B/C
Adding recursive watches on directory '/mnt/a/dir2/A/B/C/'...
[fid=94847cf7.d74a50ab.30000c9;name='file2'] /mnt/a/dir2/A/B/C/file2

Hope that helps.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fanotify_userns
[2] https://github.com/amir73il/inotify-tools/commits/fanotify_userns
[prev in list] [next in list] [prev in thread] [next in thread]