Re: [PATCH v3 1/4] add unique mount ID

[Miklos Szeredi]

On Fri, 6 Oct 2023 at 13:44, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Thu, Oct 5, 2023 at 6:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Thu, 28 Sept 2023 at 15:03, Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
> > >
> > > If a mount is released then its mnt_id can immediately be reused.  This is
> > > bad news for user interfaces that want to uniquely identify a mount.
> > >
> > > Implementing a unique mount ID is trivial (use a 64bit counter).
> > > Unfortunately userspace assumes 32bit size and would overflow after the
> > > counter reaches 2^32.
> > >
> > > Introduce a new 64bit ID alongside the old one.  Initialize the counter to
> > > 2^32, this guarantees that the old and new IDs are never mixed up.
> >
> > It occurred to me that it might make sense to make this counter
> > per-namespace.  That would allow more separation between namespaces,
> > like preventing the observation of mount creations in other
> > namespaces.
> >
>
> Preventing the observation of mount creations in other mount namespaces
> is independent of whether a global mntid namespace is used.

A local ID space makes observation of mount creations in other
namespaces impossible.  While a global ID space does not.  ID
allocation could be designed in a way that makes observation
impossible, but that basically boils down to allocating separate
ranges to each namespace, which is equivalent to identifying mounts by
an {NSID, MNTID} pair.

>
> > Does a global number make any sense?
> >
>
> I think global mntid namepsace makes notifications API a lot easier.
> A process (e.g. systemd) may set marks to watch new mounts on
> different mount namespaces.
>
> If mntid could collide in different mount namepsaces, we will either
> need to describe the mount namespace in the event or worse,
> map child mount namespace mntid to parent mount namespace
> like with uids.

Mntids are quite different from uids in that a certain ID is only
valid in a certain namespace.   There's no inheritance or sharing of
mounts.  Also mounts cannot be moved from one namespace to another
(with the exception of mounts created in an anonymous namespace).

> If we use a global mntid namespace, multi mount namespace
> watching becomes much much easier.

If the watcher wants to interpret the received event it will have to
know the namespace anyway.  Otherwise it's just a meaningless number.

> Regarding the possible scopes for watching added/removed mounts
> we could support:
> - watch parent mount for children mounts (akin to inotify directory watch)

This probably makes sense.

> - watch all mounts of a filesystem

I don't see a use case.

> - watch all mounts in mount namespace

Yes.

> - watch on entire system

Again, I don't see how this could make sense.  Each time
unshare(CLONE_NEWNS) is invoked a storm of mount creation events will
happen.

I'd imagine that watching mounts is primarily to complement the
directory tree notifications, so that all changes to the path lookup
namespace of a process could be monitored.

Thanks,
Miklos