LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

mount_setattr.2: Minor formatting fixes 

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2021-08-09 06:33:03 +02:00
parent 63097cb7be
commit 03cd41e922
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
man2/mount_setattr.2
View File

@ -379,7 +379,7 @@ and also the following
.BR xattr (7)
keys:
.RS
.IP \(bu
.IP \(bu 3
.IR security.capability ,
whenever filesystem
.BR capabilities (7)
@ -400,7 +400,7 @@ entries.
.IP
The following conditions must be met in order to create an idmapped mount:
.RS
.IP \(bu
.IP \(bu 3
The caller must have
.I CAP_SYS_ADMIN
in the initial user namespace.
@ -458,14 +458,14 @@ in
to create an idmapped mount will be the user namespace of a container.
In other scenarios it will be a dedicated user namespace associated with
a user's login session as is the case for portable home directories in
.BR systemd-homed.service (8) ).
.BR systemd-homed.service (8)).
It is also perfectly fine to create a dedicated user namespace
for the sake of idmapping a mount.
.IP
Idmapped mounts can be useful in the following
and a variety of other scenarios:
.RS
.IP \(bu
.IP \(bu 3
Sharing files between multiple users or multiple machines,
especially in complex scenarios.
For example,
@ -480,11 +480,11 @@ assign random user IDs and group IDs at login time.
.IP \(bu
Sharing files from the host with unprivileged containers.
This allows a user to avoid having to change ownership permanently through
.BR chown (2) .
.BR chown (2).
.IP \(bu
Idmapping a container's root filesystem.
Users don't need to change ownership permanently through
.BR chown (2) .
.BR chown (2).
Especially for large root filesystems, using
.BR chown (2)
can be prohibitively expensive.
@ -707,7 +707,7 @@ or
set and the flag is locked.
Mount attributes become locked on a mount if:
.RS
.IP \(bu
.IP \(bu 3
A new mount or mount tree is created causing mount propagation across user
namespaces.
The kernel will lock the aforementioned flags to protect these sensitive
@ -720,7 +720,7 @@ in
.BR unshare (2),
.BR clone (2),
or
.BR clone3 (2) .
.BR clone3 (2).
The aformentioned flags become locked to protect user namespaces from altering
sensitive mount properties.
.RE
@ -769,7 +769,7 @@ This extensibility design is very similar to other system calls such as
.BR perf_event_open (2),
.BR clone3 (2)
and
.BR openat2 (2) .
.BR openat2 (2).
.PP
Let
.I usize
@ -778,7 +778,7 @@ and let
.I ksize
be the size of the structure which the kernel supports,
then there are three cases to consider:
.IP \(bu
.IP \(bu 3
If
.I ksize
equals
@ -852,7 +852,7 @@ kernel supports can do so by conducting a binary search on
.I size
with a structure which has every byte nonzero
(to find the largest value which doesn't produce an error of
.BR E2BIG ) .
.BR E2BIG ).
.SH EXAMPLES
.EX
/*
@ -984,7 +984,7 @@ main(int argc, char *argv[])
ret = move_mount(fd_tree, "", \-EBADF, target,
MOVE_MOUNT_F_EMPTY_PATH);
if (ret == \-1)
exit_log("%m - Failed to attach mount to %s\en", target);
exit_log("%m \- Failed to attach mount to %s\en", target);
close(fd_tree);
exit(EXIT_SUCCESS);