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

[cc the correct containers list]

On Wed, Oct 16, 2024 at 2:45=E2=80=AFPM Amir Goldstein <[email protected]>=
 wrote:
>
> On Tue, Oct 15, 2024 at 4:01=E2=80=AFPM Christian Brauner <brauner@kernel=
.org> wrote:
> >
> > On Sun, Oct 13, 2024 at 06:34:18PM +0200, Amir Goldstein wrote:
> > > On Fri, May 24, 2024 at 2:35=E2=80=AFPM Amir Goldstein <amir73il@gmai=
l.com> wrote:
> > > >
> > > > On Fri, May 24, 2024 at 1:19=E2=80=AFPM Christian Brauner <brauner@=
kernel.org> wrote:
> > > > >
> > > > > A current limitation of open_by_handle_at() is that it's currentl=
y not possible
> > > > > to use it from within containers at all because we require CAP_DA=
C_READ_SEARCH
> > > > > in the initial namespace. That's unfortunate because there are sc=
enarios where
> > > > > using open_by_handle_at() from within containers.
> > > > >
> > > > > Two examples:
> > > > >
> > > > > (1) cgroupfs allows to encode cgroups to file handles and reopen =
them with
> > > > >     open_by_handle_at().
> > > > > (2) Fanotify allows placing filesystem watches they currently are=
n't usable in
> > > > >     containers because the returned file handles cannot be used.
> > > > >
> > >
> > > Christian,
> > >
> > > Follow up question:
> > > Now that open_by_handle_at(2) is supported from non-root userns,
> > > What about this old patch to allow sb/mount watches from non-root use=
rns?
> > > https://lore.kernel.org/linux-fsdevel/20230416060722.1912831-1-amir73=
[email protected]/
> > >
> > > Is it useful for any of your use cases?
> > > Should I push it forward?
> >
> > Dammit, I answered that message already yesterday but somehow it didn't
> > get sent or lost in some other way.
> >
> > I personally don't have a use-case for it but the systemd folks might
> > and it would be best to just rope them in.
>
> Lennart,
>
> I must have asked this question before, but enough time has passed so
> I am going to ask it again.
>
> Now that Christian has added support for open_by_handle_at(2) by non-root
> userns admin, it is a very low hanging fruit to support fanotify sb/mount
> watches inside userns with this simple patch [1], that was last posted in=
 2011.
>
> 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 usern=
s
> 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 ev=
ents
>      (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 us=
e cases
> where watching an idmapped mount or userns private tmpfs are useful?
>
> To try out this patch inside your favorite container/userns, you can buil=
d
> fsnotifywait with a patch to support watching inside userns [2].
> It's actually only the one lines O_DIRECTORY patch that is needed for the
> basic tmpfs userns mount case.
>
> Jan,
>
> If we do not get any buy-in from potential consumers now, do you think th=
at
> we should go through with the patch and advertise the new supported use c=
ases,
> so that users may come later on?
>
> Thanks,
> Amir.
>
> [1] https://github.com/amir73il/linux/commits/fanotify_userns/
> [2] https://github.com/amir73il/inotify-tools/commits/fanotify_userns/