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

[Christian Brauner]

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