lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Aug 2021 00:47:14 +0200 From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> To: Christian Brauner <christian.brauner@...ntu.com> Cc: mtk.manpages@...il.com, Alejandro Colomar <alx.manpages@...il.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>, linux-man <linux-man@...r.kernel.org>, Christoph Hellwig <hch@...radead.org> Subject: Re: Questions re the new mount_setattr(2) manual page 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
Powered by blists - more mailing lists