A mirror of Man pages
Go to file
Michael Kerrisk 20e6e6ed79 mount_setattr.2: Clarify the description of "detached" mounts
From email:

>> Thanks. I made it "detached". Elsewhere, the page already explains
>> that a detached mount is one that:
>>
>>           must have been created by calling open_tree(2) with the
>>           OPEN_TREE_CLONE flag and it must not already have been
>>           visible in the filesystem.
>>
>> Which seems a fine explanation.
>>
>> ????
>> But, just a thought... "visible in the filesystem" seems not quite accurate.
>> What you really mean I guess is that it must not already have been
>> /visible in the filesystem hierarchy/previously mounted/something else/,
>> right?
I suppose that I should have clarified that my main problem was
that you were using the word "filesystem" in a way that I find
unconventional/ambiguous. I mean, I normally take the term
"filesystem" to be "a storage system for folding files".
Here, you are using "filesystem" to mean something else, what
I might call like "the single directory hierarchy" or "the
filesystem hierarchy" or "the list of mount points".

> A detached mount is created via the OPEN_TREE_CLONE flag. It is a
> separate new mount so "previously mounted" is not applicable.
> A detached mount is _related_ to what the MS_BIND flag gives you with
> mount(2). However, they differ conceptually and technically. A MS_BIND
> mount(2) is always visible in the fileystem when mount(2) returns, i.e.
> it is discoverable by regular path-lookup starting within the
> filesystem.
>
> However, a detached mount can be seen as a split of MS_BIND into two
> distinct steps:
> 1. fd_tree = open_tree(OPEN_TREE_CLONE): create a new mount
> 2. move_mount(fd_tree, <somewhere>):     attach the mount to the filesystem
>
> 1. and 2. together give you the equivalent of MS_BIND.
> In between 1. and 2. however the mount is detached. For the kernel
> "detached" means that an anonymous mount namespace is attached to it
> which doen't appear in proc and has a 0 sequence number (Technically,
> there's a bit of semantical argument to be made that "attached" and
> "detached" are ambiguous as they could also be taken to mean "does or
> does not have a parent mount". This ambiguity e.g. appears in
> do_move_mount(). That's why the kernel itself calls it an "anonymous
> mount". However, an OPEN_TREE_CLONE-detached mount of course doesn't
> have a parent mount so it works.).
>
> For userspace it's better to think of detached and attached in terms of
> visibility in the filesystem or in a mount namespace. That's more
> straightfoward, more relevant, and hits the target in 90% of the cases.
>
> However, the better and clearer picture is to say that a
> OPEN_TREE_CLONE-detached mount is a mount that has never been
> move_mount()ed. Which in turn can be defined as the detached mount has
> never been made visible in a mount namespace. Once that has happened the
> mount is irreversibly an attached mount.
>
> I keep thinking that maybe we should just say "anonymous mount"
> everywhere. So changing the wording to:
I'm not against the word "detached". To user space, I think it is a
little more meaningful than "anonymous". For the moment, I'll stay with
"detached", but if you insist on "anonymous", I'll probably change it.

> [...]
> EINVAL The mount that is to be ID mapped is not an anonymous mount;
> that is, the mount has already been visible in a mount namespace.
I like that text *a lot* better! Thanks very much for suggesting
wordings. It makes my life much easier.

I've made the text:

       EINVAL The mount that is to be ID mapped is not a detached
              mount; that is, the mount has not previously been
              visible in a mount namespace.

> [...]
> The mount must be an anonymous mount; that is, it must have been
> created by calling open_tree(2) with the OPEN_TREE_CLONE flag and it
> must not already have been visible in a mount namespace, i.e. it must
> not have been attached to the filesystem hierarchy with syscalls such
> as move_mount() syscall.
And that too! I've made the text:

       •  The mount must be a detached mount; that is, it must have
          been created by calling open_tree(2) with the
          OPEN_TREE_CLONE flag and it must not already have been
          visible in a mount namespace.  (To put things another way:
          the mount must not have been attached to the filesystem
          hierarchy with a system call such as move_mount(2).)

Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
2021-08-12 07:33:53 +02:00
man1 ldd.1: Fix example command 2021-08-09 02:32:37 +02:00
man2 mount_setattr.2: Clarify the description of "detached" mounts 2021-08-12 07:33:53 +02:00
man3 fanotify_mark.2, futimesat.2, mount_setattr.2, statx.2, symlink.2, mkfifo.3: Refer the reader to openat(2) for explanation of why 'dirfd' is useful 2021-08-12 05:45:21 +02:00
man4 console_codes.4: tfix 2021-07-26 01:31:54 +02:00
man5 localedef.1, access.2, ioctl_console.2, ioctl_fslabel.2, openat2.2, write.2, dlsym.3, getopt.3, nl_langinfo.3, termios.3, xcrypt.3, hosts.equiv.5, nsswitch.conf.5, cgroups.7, man-pages.7, netlink.7, system_data_types.7: srcfix: semantic newlines 2021-08-09 02:32:37 +02:00
man6 intro.6: wfix 2017-08-25 21:41:03 +02:00
man7 mount_namespaces.7: tfix 2021-08-12 07:33:53 +02:00
man8 ld.so.8: Document --list-tunables option added in glibc 2.33 2021-07-05 09:33:57 +12:00
scripts scripts/bash_aliases: tfix 2021-08-08 01:02:32 +02:00
.gitignore .gitignore: Tweaks to Alex's .gitignore 2021-05-11 04:34:03 +12:00
CONTRIBUTING CONTRIBUTING: New file with some starting tips on how to contribute 2019-09-13 15:59:08 +02:00
Changes Start of man-pages-5.13: updating Changes and Changes.old 2021-06-22 13:04:07 +12:00
Changes.old Start of man-pages-5.13: updating Changes and Changes.old 2021-06-22 13:04:07 +12:00
MAINTAINER_NOTES MAINTAINER_NOTES: tfix 2021-01-24 23:30:51 +01:00
Makefile Makefile, README: Break installation into a target for each mandir 2021-06-10 10:32:59 +12:00
README Makefile, README: Break installation into a target for each mandir 2021-06-10 10:32:59 +12:00
man-pages-5.13.Announce Start of man-pages-5.13: updating .Announce and .lsm files 2021-06-22 13:04:07 +12:00
man-pages-5.13.lsm Start of man-pages-5.13: updating .Announce and .lsm files 2021-06-22 13:04:07 +12:00

README

This package contains Linux man pages for sections 1 through 8.  Some
more information is given in the 'man-pages-x.y.Announce' file.

Homepage
========
For information about the Linux man-pages project, see
http://www.kernel.org/doc/man-pages/index.html.

Bug reports and contributing
============================
If you have corrections and additions to suggest, see
http://www.kernel.org/doc/man-pages/contributing.html
(Although there is a mirror of this repository on GitHub,
please don't report issues via the GitHub issue tracker!)

For further information on contributing, see the CONTRIBUTING file.

Installing and uninstalling
===========================
"make install" will copy these man pages to /usr/local/share/man/man[1-8].

To install to a path different from /usr/local, use
"make install prefix=/install/path".

"make remove" or "make uninstall" will remove any man page in this
distribution from its destination.  Use with caution, and remember to
use "prefix" if desired, as with the "install" target.

To install only a specific man section (mandir) such as man3, use
"make install-man3".  Similar syntax can be used to uninstall a
specific man section, such as man7: "make uninstall-man7".

"make" or "make all" will perform "make uninstall" followed by "make
install".

Consider using multiple threads (at least 2) when installing
these man pages, as the Makefile is optimized for multiple threads:
"make -j install".

Copyrights
==========
See the 'man-pages-x.y.Announce' file.