Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Cc:     mtk.manpages@gmail.com, Alejandro Colomar <alx.manpages@gmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        linux-man <linux-man@vger.kernel.org>,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: Questions re the new mount_setattr(2) manual page
To:     Christian Brauner <christian.brauner@ubuntu.com>
References: <b58e2537-03f4-6f6c-4e1b-8ddd989624cc@gmail.com>
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Message-ID: <d5a8061a-3d8a-6353-5158-8feee0156c6b@gmail.com>
Date:   Wed, 11 Aug 2021 00:47:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <b58e2537-03f4-6f6c-4e1b-8ddd989624cc@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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