LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
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
Date: Wed, 11 Aug 2021 00:47:14 +0200	[thread overview]
Message-ID: <d5a8061a-3d8a-6353-5158-8feee0156c6b@gmail.com> (raw)
In-Reply-To: <b58e2537-03f4-6f6c-4e1b-8ddd989624cc@gmail.com>

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

  parent reply	other threads:[~2021-08-10 22:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10  1:38 Michael Kerrisk (man-pages)
2021-08-10  7:12 ` Michael Kerrisk (man-pages)
2021-08-10 14:11   ` Christian Brauner
2021-08-10 19:30     ` Michael Kerrisk (man-pages)
2021-08-10 14:32 ` Christian Brauner
2021-08-10 21:06   ` Michael Kerrisk (man-pages)
2021-08-11 10:07     ` Christian Brauner
2021-08-12  5:36       ` Michael Kerrisk (man-pages)
2021-08-12  9:08         ` Christian Brauner
2021-08-12 22:32           ` Michael Kerrisk (man-pages)
2021-08-10 22:47 ` Michael Kerrisk (man-pages) [this message]
2021-08-11 10:40   ` Christian Brauner
2021-08-12  5:36     ` Michael Kerrisk (man-pages)
2021-08-12  8:38       ` Christian Brauner
2021-08-13  1:25         ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5a8061a-3d8a-6353-5158-8feee0156c6b@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --subject='Re: Questions re the new mount_setattr(2) manual page' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).