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
