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?
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?)
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?
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.
Thanks,
Michael
