Re: Questions re the new mount_setattr(2) manual page

From: Christian Brauner
Date: Wed Aug 11 2021 - 06:40:42 EST


On Wed, Aug 11, 2021 at 12:47:14AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Christian,
>
> Some further questions...
>
> In ERRORS there is:
>
> EINVAL The underlying filesystem is mounted in a user namespace.
>
> I don't understand this. What does it mean?

The underlying filesystem has been mounted in a mount namespace that is
owned by a non-initial user namespace (Think of sysfs, overlayfs etc.).

>
> Also, there is this:
>
> ENOMEM When changing mount propagation to MS_SHARED, a new peer
> group ID needs to be allocated for all mounts without a
> peer group ID set. Allocation of this peer group ID has
> failed.
>
> ENOSPC When changing mount propagation to MS_SHARED, a new peer
> group ID needs to be allocated for all mounts without a
> peer group ID set. Allocation of this peer group ID can
> fail. Note that technically further error codes are possi‐
> ble that are specific to the ID allocation implementation
> used.
>
> What is the difference between these two error cases? (That is, in what
> circumstances will one get ENOMEM vs ENOSPC and vice versa?)

I did really wonder whether to even include those errors and I regret
having included them because they aren't worth a detailed discussion as
I'd consider them kernel internal relevant errors rather than userspace
relevant errors. In essence, peer group ids are allocated using the id
infrastructure of the kernel. It can fail for two main reasons:

1. ENOMEM there's not enough memory to allocate the relevant internal
structures needed for the bitmap.
2. ENOSPC we ran out of ids, i.e. someone has somehow managed to
allocate so many peer groups and managed to keep the kernel running
(???) that the ida has ran out of ids.

Feel free to just drop those errors.

>
> And then:
>
> EPERM One of the mounts had at least one of MOUNT_ATTR_NOATIME,
> MOUNT_ATTR_NODEV, MOUNT_ATTR_NODIRATIME, MOUNT_ATTR_NOEXEC,
> MOUNT_ATTR_NOSUID, or MOUNT_ATTR_RDONLY set and the flag is
> locked. Mount attributes become locked on a mount if:
>
> • A new mount or mount tree is created causing mount prop‐
> agation across user namespaces. The kernel will lock
>
> Propagation is done across mont points, not user namespaces.
> should "across user namespaces" be "to a mount namespace owned
> by a different user namespace"? Or something else?

That's really splitting hairs. Of course this means that we're
propagating into a mount namespace that is owned by a different user
namespace though "crossing user namespaces" might have been the better
choice.

>
> the aforementioned flags to protect these sensitive
> properties from being altered.
>
> • A new mount and user namespace pair is created. This
> happens for example when specifying CLONE_NEWUSER |
> CLONE_NEWNS in unshare(2), clone(2), or clone3(2). The
> aforementioned flags become locked to protect user name‐
> spaces from altering sensitive mount properties.
>
> Again, this seems imprecise. Should it say something like:
> "... to prevent changes to sensitive mount properties in the new
> mount namespace" ? Or perhaps you have a better wording.

That's not imprecise. What you want to protect against is altering
sensitive mount properties from within a user namespace irrespective of
whether or not the user namespace actually owns the mount namespace,
i.e. even if you own the mount namespace you shouldn't be able to alter
those properties. I concede though that "protect" should've been
"prevent".

You could probably say:

A new mount and user namespace pair is created. This
happens for example when specifying CLONE_NEWUSER |
CLONE_NEWNS in unshare(2), clone(2), or clone3(2).
The aforementioned flags become locked in the new mount
namespace to prevent sensitive mount properties from being
altered.
Since the newly created mount namespace will be owned by the
newly created user namespace a caller privileged in the newly
created user namespace would be able to alter senstive
mount properties. For example, without locking the read-only
property for the mounts in the new mount namespace such a caller
would be able to remount them read-write.

(Fwiw, in this scenario there's a bit of (moderately sane) strangeness.
A CLONE_NEWUSER | CLONE_NEWMNT will cause even stronger protection to
kick in. For all mounts not marked as expired MNT_LOCKED will be set
which means that a umount() on any such mount copied from the previous
mount namespace will yield EINVAL implying from userspace' perspective
it's not mounted - granted EINVAL is the ioctl() of multiplexing errnos
- whereas a remount to alter a locked flag will yield EPERM.)

Christian