Subject: Setting mount propagation type in new mount API

Hello David, Miklos,

I've been looking at the new mount API (fsopen(), fsconfig(),
fsmount(), move_mount(), etc.) and among the details that remain
mysterious to me is this: how does one set the propagation type
(private/shared/slave/unbindable) of a new mount and change the
propagation type of an existing mount?

I've looked at the kernel source for a bit, and did not see how this
is possible.

The draft manual pages sent out a few months ago provide little clue,
with the only hint being in the draft fsopen(2) page, which says of
fsmount():

fsmount() takes the file descriptor returned by fsopen() and cre‐
ates a mount object for the filesystem root specified there. The
attributes of the mount object are set from the mount_attrs param‐
eter. The attributes specify the propagation and mount restric‐
tions to be applied to accesses through this mount.

However, that text appears *not* to be true. The 'mount_attrs'
argument of fsmount() does not seem to permit specification of
propagation type, since in the kernel there is this check:

if (attr_flags & ~(MOUNT_ATTR_RDONLY |
MOUNT_ATTR_NOSUID |
MOUNT_ATTR_NODEV |
MOUNT_ATTR_NOEXEC |
MOUNT_ATTR__ATIME |
MOUNT_ATTR_NODIRATIME))
return -EINVAL;

Thanks,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


2020-05-15 13:09:19

by Miklos Szeredi

[permalink] [raw]
Subject: Re: Setting mount propagation type in new mount API

On Fri, May 15, 2020 at 1:40 PM Michael Kerrisk (man-pages)
<[email protected]> wrote:
>
> Hello David, Miklos,
>
> I've been looking at the new mount API (fsopen(), fsconfig(),
> fsmount(), move_mount(), etc.) and among the details that remain
> mysterious to me is this: how does one set the propagation type
> (private/shared/slave/unbindable) of a new mount and change the
> propagation type of an existing mount?

Existing mount can be chaged with mount(NULL, path, NULL, MS_$(propflag), NULL).

To do that with a detached mount created by fsmount(2) the
"/proc/self/fd/$fd" trick can be used.

The plan was to introduce a mount_setattr(2) syscall, but that hasn't
happened yet... I'm not sure we should be adding propagation flags to
fsmount(2), since that is a less generic mechanism than
mount_setattr(2) or just plain mount(2) as shown above.

Thanks,
Miklos

2020-05-15 13:22:03

by Miklos Szeredi

[permalink] [raw]
Subject: Re: Setting mount propagation type in new mount API

On Fri, May 15, 2020 at 3:04 PM Miklos Szeredi <[email protected]> wrote:
>
> On Fri, May 15, 2020 at 1:40 PM Michael Kerrisk (man-pages)
> <[email protected]> wrote:
> >
> > Hello David, Miklos,
> >
> > I've been looking at the new mount API (fsopen(), fsconfig(),
> > fsmount(), move_mount(), etc.) and among the details that remain
> > mysterious to me is this: how does one set the propagation type
> > (private/shared/slave/unbindable) of a new mount and change the
> > propagation type of an existing mount?
>
> Existing mount can be chaged with mount(NULL, path, NULL, MS_$(propflag), NULL).
>
> To do that with a detached mount created by fsmount(2) the
> "/proc/self/fd/$fd" trick can be used.
>
> The plan was to introduce a mount_setattr(2) syscall, but that hasn't
> happened yet... I'm not sure we should be adding propagation flags to
> fsmount(2), since that is a less generic mechanism than
> mount_setattr(2) or just plain mount(2) as shown above.

Also note that only setting MS_SHARED makes sense on a new mount
returned by fsmount(2) because

- MS_PRIVATE is a no op, due to mount already being private

- same for MS_SLAVE, since it's only different from MS_PRIVATE on
mounts receiving propagation, which a new mount by definition isn't

- MS_UNBINDABLE just prevents move_mount(2) from working so that's
not really useful, though at least it does something

A more interesting issue is whether we'd want to control the
propagation of the target when moving into a shared tree. I.e. should
there be a MOVE_MOUNT_DONTPROPAGATE flag for move_mount(20 that
prevents the new mount from being propagated...

Thanks,
Miklos

2020-05-18 14:32:36

by David Howells

[permalink] [raw]
Subject: Re: Setting mount propagation type in new mount API

Michael Kerrisk (man-pages) <[email protected]> wrote:

> I've been looking at the new mount API (fsopen(), fsconfig(),
> fsmount(), move_mount(), etc.) and among the details that remain
> mysterious to me is this: how does one set the propagation type
> (private/shared/slave/unbindable) of a new mount and change the
> propagation type of an existing mount?

Christian said he was going to have a go at writing mount_setattr(). It's not
trivial as it has to be able to handle AT_RECURSIVE.

David

2020-05-18 14:44:11

by Christian Brauner

[permalink] [raw]
Subject: Re: Setting mount propagation type in new mount API

On Mon, May 18, 2020 at 03:30:34PM +0100, David Howells wrote:
> Michael Kerrisk (man-pages) <[email protected]> wrote:
>
> > I've been looking at the new mount API (fsopen(), fsconfig(),
> > fsmount(), move_mount(), etc.) and among the details that remain
> > mysterious to me is this: how does one set the propagation type
> > (private/shared/slave/unbindable) of a new mount and change the
> > propagation type of an existing mount?
>
> Christian said he was going to have a go at writing mount_setattr(). It's not
> trivial as it has to be able to handle AT_RECURSIVE.

Right, I've put this on my roadmap now. It's becoming more urgent for us
too since I've already switched over a few bits to the new mount api to
make use of detached/anonymous mounts.
I've planned to start working on a version early next week.

Christian