Re: fanotify sb/mount watch inside userns (Was: [PATCH RFC] : fhandle: relax open_by_handle_at() permission checks)

Amir Goldstein <[email protected]> Fri, 18 Apr 2025 13:32:48 +0200
Newsgroups dev.linux.lists.containers,org.kernel.vger.linux-fsdevel
Message-ID <CAOQ4uxgwfQNM=cRBJ0BJ-UtZ1R=v3uuFrOfLxWCr5c0WA_Nh3w@mail.gmail.com>
On Wed, Oct 16, 2024 at 2:53=E2=80=AFPM Amir Goldstein <[email protected]>=
 wrote:
>
...
> > > > Christian,
> > > >
> > > > Follow up question:
> > > > Now that open_by_handle_at(2) is supported from non-root userns,
> > > > What about this old patch [1] to allow sb/mount watches from non-ro=
ot userns?
> > > >
> > > >
...
> >
> > My question is whether this is useful, because there are still a few
> > limitations.
> > I will start with what is possible with this patch:
> > 1. Watch an entire tmpfs filesystem that was mounted inside userns
> > 2. Watch an entire overlayfs filesystem that was mounted [*] inside use=
rns
> > 3. Watch an entire mount [**] of any [***] filesystem that was
> > idmapped mounted into userns
> >
> > Now the the fine prints:
> > [*] Overlayfs sb/mount CAN be watched, but decoding file handle in
> > events to path
> >      only works if overlayfs is mounted with mount option
> > nfs_export=3Don, which conflicts
> >      with mount option metacopy=3Don, which is often used in containers
> > (e.g. podman)
> > [**] Watching a mount is only possible with the legacy set of fanotify =
events
> >      (i.e. open,close,access,modify) so this is less useful for
> > directory tree change tracking
> > [***] Watching an idmapped mount has the same limitations as watching
> > an sb/mount
> >      in the root userns, namely, filesystem needs to have a non zero
> > fsid (so not FUSE)
> >      and filesystem needs to have a uniform fsid (so not btrfs
> > subvolume), although
> >      with some stretch, I could make watching an idmapped mount of
> > btrfs subvol work.
> >
> > No support for watching btrfs subvol and overlayfs with metacopy=3Don,
> > reduces the attractiveness for containers, but perhaps there are still =
use cases
> > where watching an idmapped mount or userns private tmpfs are useful?
> >
> > To try out this patch inside your favorite container/userns, you can bu=
ild
> > fsnotifywait with a patch to support watching inside userns [2].
> > It's actually only the one lines O_DIRECTORY patch that is needed for t=
he
> > basic tmpfs userns mount case.
> >
> > Jan,
> >
> > If we do not get any buy-in from potential consumers now, do you think =
that
> > we should go through with the patch and advertise the new supported use=
 cases,
> > so that users may come later on?
> >

Hi guys,

The fine print section in the above "is it useful" question is quite comple=
x.
Maybe that explains why I got no response ;)

I can now ask another flavor of the question:

Is it useful to allow FAN_MARK_MNTNS watches from non-root userns?

Just to make sure that I get it right, the unique mntid that is reported wi=
th
mount attach/detach events is not namespaced right?

Anyway, this functionality has become a priority for me, so I will
work on adapting the old patch [3] to mntns marks and post v2.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fanotify_userns/
[2] https://github.com/amir73il/inotify-tools/commits/fanotify_userns/
[3] https://lore.kernel.org/linux-fsdevel/20230416060722.1912831-1-amir73il=
@gmail.com/