1 .\" Copyright (c) 2013, 2014 by Michael Kerrisk <mtk.manpages@gmail.com>
2 .\" and Copyright (c) 2012, 2014 by Eric W. Biederman <ebiederm@xmission.com>
4 .\" Permission is granted to make and distribute verbatim copies of this
5 .\" manual provided the copyright notice and this permission notice are
6 .\" preserved on all copies.
8 .\" Permission is granted to copy and distribute modified versions of this
9 .\" manual under the conditions for verbatim copying, provided that the
10 .\" entire resulting derived work is distributed under the terms of a
11 .\" permission notice identical to this one.
13 .\" Since the Linux kernel and libraries are constantly changing, this
14 .\" manual page may be incorrect or out-of-date. The author(s) assume no
15 .\" responsibility for errors or omissions, or for damages resulting from
16 .\" the use of the information contained herein. The author(s) may not
17 .\" have taken the same level of care in the production of this manual,
18 .\" which is licensed free of charge, as they might when working
21 .\" Formatted or processed versions of this manual, if unaccompanied by
22 .\" the source, must acknowledge the copyright and authors of this work.
25 .TH USER_NAMESPACES 7 2013-01-14 "Linux" "Linux Programmer's Manual"
27 user_namespaces \- overview of Linux user_namespaces
29 For an overview of namespaces, see
32 User namespaces isolate security-related identifiers and attributes,
34 user IDs and group IDs (see
39 .\" FIXME: This page says very little about the interaction
40 .\" of user namespaces and keys. Add something on this topic.
42 .BR capabilities (7)).
43 A process's user and group IDs can be different
44 inside and outside a user namespace.
46 a process can have a normal unprivileged user ID outside a user namespace
47 while at the same time having a user ID of 0 inside the namespace;
49 the process has full privileges for operations inside the user namespace,
50 but is unprivileged for operations outside the namespace.
52 .\" ============================================================
54 .SS Nested namespaces, namespace membership
55 User namespaces can be nested;
56 that is, each user namespace\(emexcept the initial ("root")
57 namespace\(emhas a parent user namespace,
58 and can have zero or more child user namespaces.
59 The parent user namespace is the user namespace
60 of the process that creates the user namespace via a call to
68 The kernel imposes (since version 3.11) a limit of 32 nested levels of
69 .\" commit 8742f229b635bf1c1c84a3dfe5e47c814c20b5c8
71 .\" FIXME Explain the rationale for this limit. (What is the rationale?)
76 that would cause this limit to be exceeded fail with the error
79 Each process is a member of exactly one user namespace.
86 flag is a member of the same user namespace as its parent.
87 A single-threaded process can join another user namespace with
92 upon doing so, it gains a full set of capabilities in that namespace.
100 flag makes the new child process (for
104 a member of the new user namespace created by the call.
106 .\" ============================================================
109 The child process created by
113 flag starts out with a complete set
114 of capabilities in the new user namespace.
115 Likewise, a process that creates a new user namespace using
117 or joins an existing user namespace using
119 gains a full set of capabilities in that namespace.
121 that process has no capabilities in the parent (in the case of
123 or previous (in the case of
128 even if the new namespace is created or joined by the root user
129 (i.e., a process with user ID 0 in the root namespace).
133 will cause a process's capabilities to be recalculated (see
134 .BR capabilities (7)),
135 so that usually, unless it has a user ID of 0 within the namespace,
136 it will lose all capabilities.
137 See the discussion of user and group ID mappings, below.
146 flag sets the "securebits" flags
148 .BR capabilities (7))
149 to their default values (all flags disabled) in the child (for
155 Note that because the caller no longer has capabilities
156 in its original user namespace after a call to
158 it is not possible for a process to reset its "securebits" flags while
159 retaining its user namespace membership by using a pair of
161 calls to move to another user namespace and then return to
162 its original user namespace.
164 Having a capability inside a user namespace
165 permits a process to perform operations (that require privilege)
166 only on resources governed by that namespace.
167 The rules for determining whether or not a process has a capability
168 in a particular user namespace are as follows:
170 A process has a capability inside a user namespace
171 if it is a member of that namespace and
172 it has the capability in its effective capability set.
173 A process can gain capabilities in its effective capability
175 For example, it may execute a set-user-ID program or an
176 executable with associated file capabilities.
178 a process may gain capabilities via the effect of
183 as already described.
184 .\" In the 3.8 sources, see security/commoncap.c::cap_capable():
186 If a process has a capability in a user namespace,
187 then it has that capability in all child (and further removed descendant)
190 .\" * The owner of the user namespace in the parent of the
191 .\" * user namespace has all caps.
192 When a user namespace is created, the kernel records the effective
193 user ID of the creating process as being the "owner" of the namespace.
194 .\" (and likewise associates the effective group ID of the creating process
195 .\" with the namespace).
196 A process that resides
197 in the parent of the user namespace
198 .\" See kernel commit 520d9eabce18edfef76a60b7b839d54facafe1f9 for a fix
200 and whose effective user ID matches the owner of the namespace
201 has all capabilities in the namespace.
202 .\" This includes the case where the process executes a set-user-ID
203 .\" program that confers the effective UID of the creator of the namespace.
204 By virtue of the previous rule,
205 this means that the process has all capabilities in all
206 further removed descendant user namespaces as well.
208 .\" ============================================================
210 .SS Interaction of user namespaces and other types of namespaces
211 Starting in Linux 3.8, unprivileged processes can create user namespaces,
212 and mount, PID, IPC, network, and UTS namespaces can be created with just the
214 capability in the caller's user namespace.
218 is specified along with other
224 call, the user namespace is guaranteed to be created first,
229 privileges over the remaining namespaces created by the call.
230 Thus, it is possible for an unprivileged caller to specify this combination
233 When a new IPC, mount, network, PID, or UTS namespace is created via
237 the kernel records the user namespace of the creating process against
239 (This association can't be changed.)
240 When a process in the new namespace subsequently performs
241 privileged operations that operate on global
242 resources isolated by the namespace,
243 the permission checks are performed according to the process's capabilities
244 in the user namespace that the kernel associated with the new namespace.
246 .\" ============================================================
248 .SS Restrictions on mount namespaces
250 Note the following points with respect to mount namespaces:
252 A mount namespace has an owner user namespace.
253 A mount namespace whose owner user namespace is different from
254 the owner user namespace of its parent mount namespace is
255 considered a less privileged mount namespace.
257 When creating a less privileged mount namespace,
258 shared mounts are reduced to slave mounts.
259 This ensures that mappings performed in less
260 privileged mount namespaces will not propagate to more privileged
264 .\" What does "come as a single unit from more privileged mount" mean?
265 Mounts that come as a single unit from more privileged mount are
266 locked together and may not be separated in a less privileged mount
275 and the "atime" flags
279 settings become locked
280 .\" commit 9566d6742852c527bf5af38af5cbb878dad75705
281 .\" Author: Eric W. Biederman <ebiederm@xmission.com>
282 .\" Date: Mon Jul 28 17:26:07 2014 -0700
284 .\" mnt: Correct permission checks in do_remount
286 when propagated from a more privileged to
287 a less privileged mount namespace,
288 and may not be changed in the less privileged mount namespace.
290 .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree))
291 A file or directory that is a mount point in one namespace that is not
292 a mount point in another namespace, may be renamed, unlinked, or removed
294 in the mount namespace in which it is not a mount point
295 (subject to the usual permission checks).
297 Previously, attempting to unlink, rename, or remove a file or directory
298 that was a mount point in another mount namespace would result in the error
300 That behavior had technical problems of enforcement (e.g., for NFS)
301 and permitted denial-of-service attacks against more privileged users.
302 (i.e., preventing individual files from being updated
303 by bind mounting on top of them).
305 .\" ============================================================
307 .SS User and group ID mappings: uid_map and gid_map
308 When a user namespace is created,
309 it starts out without a mapping of user IDs (group IDs)
310 to the parent user namespace.
312 .IR /proc/[pid]/uid_map
314 .IR /proc/[pid]/gid_map
315 files (available since Linux 3.5)
316 .\" commit 22d917d80e842829d0ca0a561967d728eb1d6303
317 expose the mappings for user and group IDs
318 inside the user namespace for the process
320 These files can be read to view the mappings in a user namespace and
321 written to (once) to define the mappings.
323 The description in the following paragraphs explains the details for
327 but each instance of "user ID" is replaced by "group ID".
331 file exposes the mapping of user IDs from the user namespace
334 to the user namespace of the process that opened
336 (but see a qualification to this point below).
337 In other words, processes that are in different user namespaces
338 will potentially see different values when reading from a particular
340 file, depending on the user ID mappings for the user namespaces
341 of the reading processes.
345 file specifies a 1-to-1 mapping of a range of contiguous
346 user IDs between two user namespaces.
347 (When a user namespace is first created, this file is empty.)
348 The specification in each line takes the form of
349 three numbers delimited by white space.
350 The first two numbers specify the starting user ID in
351 each of the two user namespaces.
352 The third number specifies the length of the mapped range.
353 In detail, the fields are interpreted as follows:
355 The start of the range of user IDs in
356 the user namespace of the process
359 The start of the range of user
360 IDs to which the user IDs specified by field one map.
361 How field two is interpreted depends on whether the process that opened
365 are in the same user namespace, as follows:
368 If the two processes are in different user namespaces:
369 field two is the start of a range of
370 user IDs in the user namespace of the process that opened
373 If the two processes are in the same user namespace:
374 field two is the start of the range of
375 user IDs in the parent user namespace of the process
377 This case enables the opener of
379 (the common case here is opening
380 .IR /proc/self/uid_map )
381 to see the mapping of user IDs into the user namespace of the process
382 that created this user namespace.
385 The length of the range of user IDs that is mapped between the two
388 System calls that return user IDs (group IDs)\(emfor example,
391 and the credential fields in the structure returned by
392 .BR stat (2)\(emreturn
393 the user ID (group ID) mapped into the caller's user namespace.
395 When a process accesses a file, its user and group IDs
396 are mapped into the initial user namespace for the purpose of permission
397 checking and assigning IDs when creating a file.
398 When a process retrieves file user and group IDs via
400 the IDs are mapped in the opposite direction,
401 to produce values relative to the process user and group ID mappings.
403 The initial user namespace has no parent namespace,
404 but, for consistency, the kernel provides dummy user and group
405 ID mapping files for this namespace.
410 is the same) from a shell in the initial namespace shows:
414 $ \fBcat /proc/$$/uid_map\fP
419 This mapping tells us
420 that the range starting at user ID 0 in this namespace
421 maps to a range starting at 0 in the (nonexistent) parent namespace,
422 and the length of the range is the largest 32-bit unsigned integer.
424 .\" ============================================================
426 .SS Defining user and group ID mappings: writing to uid_map and gid_map
428 After the creation of a new user namespace, the
432 of the processes in the namespace may be written to
434 to define the mapping of user IDs in the new user namespace.
435 An attempt to write more than once to a
437 file in a user namespace fails with the error
439 Similar rules apply for
446 must conform to the following rules:
448 The three fields must be valid numbers,
449 and the last field must be greater than 0.
451 Lines are terminated by newline characters.
453 There is an (arbitrary) limit on the number of lines in the file.
454 As at Linux 3.8, the limit is five lines.
455 In addition, the number of bytes written to
456 the file must be less than the system page size,
457 .\" FIXME(Eric): the restriction "less than" rather than "less than or equal"
458 .\" seems strangely arbitrary. Furthermore, the comment does not agree
459 .\" with the code in kernel/user_namespace.c. Which is correct?
460 and the write must be performed at the start of the file (i.e.,
464 can't be used to write to nonzero offsets in the file).
466 The range of user IDs (group IDs)
467 specified in each line cannot overlap with the ranges
469 In the initial implementation (Linux 3.8), this requirement was
470 satisfied by a simplistic implementation that imposed the further
472 the values in both field 1 and field 2 of successive lines must be
473 in ascending numerical order,
474 which prevented some otherwise valid maps from being created.
476 .\" commit 0bd14b4fd72afd5df41e9fd59f356740f22fceba
477 fix this limitation, allowing any valid set of nonoverlapping maps.
479 At least one line must be written to the file.
481 Writes that violate the above rules fail with the error
484 In order for a process to write to the
485 .I /proc/[pid]/uid_map
486 .RI ( /proc/[pid]/gid_map )
487 file, all of the following requirements must be met:
489 The writing process must have the
492 capability in the user namespace of the process
495 The writing process must be in either the user namespace of the process
497 or inside the parent user namespace of the process
500 The mapped user IDs (group IDs) must in turn have a mapping
501 in the parent user namespace.
503 One of the following is true:
509 consists of a single line that maps the writing process's filesystem user ID
510 (group ID) in the parent user namespace to a user ID (group ID)
511 in the user namespace.
512 The usual case here is that this single line provides a mapping for user ID
513 of the process that created the namespace.
518 capability in the parent user namespace.
519 Thus, a privileged process can make mappings to arbitrary user IDs (group IDs)
520 in the parent user namespace.
523 Writes that violate the above rules fail with the error
526 .\" ============================================================
528 .SS Unmapped user and group IDs
530 There are various places where an unmapped user ID (group ID)
531 may be exposed to user space.
532 For example, the first process in a new user namespace may call
534 before a user ID mapping has been defined for the namespace.
535 In most such cases, an unmapped user ID is converted
536 .\" from_kuid_munged(), from_kgid_munged()
537 to the overflow user ID (group ID);
538 the default value for the overflow user ID (group ID) is 65534.
539 See the descriptions of
540 .IR /proc/sys/kernel/overflowuid
542 .IR /proc/sys/kernel/overflowgid
546 The cases where unmapped IDs are mapped in this fashion include
547 system calls that return user IDs
551 credentials passed over a UNIX domain socket,
553 credentials returned by
556 and the System V IPC "ctl"
559 credentials exposed by
562 .IR /proc/sysvipc/* ,
563 credentials returned via the
567 received with a signal (see
569 credentials written to the process accounting file (see
571 and credentials returned with POSIX message queue notifications (see
574 There is one notable case where unmapped user and group IDs are
576 .\" from_kuid(), from_kgid()
577 .\" Also F_GETOWNER_UIDS is an exception
578 converted to the corresponding overflow ID value.
583 file in which there is no mapping for the second field,
584 that field is displayed as 4294967295 (\-1 as an unsigned integer);
586 .\" ============================================================
588 .SS Set-user-ID and set-group-ID programs
590 When a process inside a user namespace executes
591 a set-user-ID (set-group-ID) program,
592 the process's effective user (group) ID inside the namespace is changed
593 to whatever value is mapped for the user (group) ID of the file.
594 However, if either the user
596 the group ID of the file has no mapping inside the namespace,
597 the set-user-ID (set-group-ID) bit is silently ignored:
598 the new program is executed,
599 but the process's effective user (group) ID is left unchanged.
600 (This mirrors the semantics of executing a set-user-ID or set-group-ID
601 program that resides on a filesystem that was mounted with the
603 flag, as described in
606 .\" ============================================================
610 When a process's user and group IDs are passed over a UNIX domain socket
611 to a process in a different user namespace (see the description of
615 they are translated into the corresponding values as per the
616 receiving process's user and group ID mappings.
619 Namespaces are a Linux-specific feature.
622 Over the years, there have been a lot of features that have been added
623 to the Linux kernel that have been made available only to privileged users
624 because of their potential to confuse set-user-ID-root applications.
625 In general, it becomes safe to allow the root user in a user namespace to
626 use those features because it is impossible, while in a user namespace,
627 to gain more privilege than the root user of a user namespace has.
629 .\" ============================================================
632 Use of user namespaces requires a kernel that is configured with the
635 User namespaces require support in a range of subsystems across
637 When an unsupported subsystem is configured into the kernel,
638 it is not possible to configure user namespaces support.
640 As at Linux 3.8, most relevant subsystems supported user namespaces,
641 but a number of filesystems did not have the infrastructure needed
642 to map user and group IDs between user namespaces.
643 Linux 3.9 added the required infrastructure support for many of
644 the remaining unsupported filesystems
645 (Plan 9 (9P), Andrew File System (AFS), Ceph, CIFS, CODA, NFS, and OCFS2).
646 Linux 3.11 added support the last of the unsupported major filesystems,
647 .\" commit d6970d4b726cea6d7a9bc4120814f95c09571fc3
651 The program below is designed to allow experimenting with
652 user namespaces, as well as other types of namespaces.
653 It creates namespaces as specified by command-line options and then executes
654 a command inside those namespaces.
657 function inside the program provide a full explanation of the program.
658 The following shell session demonstrates its use.
660 First, we look at the run-time environment:
664 $ \fBuname -rs\fP # Need Linux 3.8 or later
666 $ \fBid -u\fP # Running as unprivileged user
673 Now start a new shell in new user
679 namespaces, with user ID
683 1000 mapped to 0 inside the user namespace:
687 $ \fB./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash\fP
691 The shell has PID 1, because it is the first process in the new
701 Inside the user namespace, the shell has user and group ID 0,
702 and a full set of permitted and effective capabilities:
706 bash$ \fBcat /proc/$$/status | egrep '^[UG]id'\fP
709 bash$ \fBcat /proc/$$/status | egrep '^Cap(Prm|Inh|Eff)'\fP
710 CapInh: 0000000000000000
711 CapPrm: 0000001fffffffff
712 CapEff: 0000001fffffffff
718 filesystem and listing all of the processes visible
719 in the new PID namespace shows that the shell can't see
720 any processes outside the PID namespace:
724 bash$ \fBmount -t proc proc /proc\fP
726 PID TTY STAT TIME COMMAND
728 22 pts/3 R+ 0:00 ps ax
734 /* userns_child_exec.c
736 Licensed under GNU General Public License v2 or later
738 Create a child process that executes a shell command in new
739 namespace(s); allow UID and GID mappings to be specified when
740 creating a user namespace.
746 #include <sys/wait.h>
754 /* A simple error\-handling function: print an error message based
755 on the value in \(aqerrno\(aq and terminate the calling process */
757 #define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \\
761 char **argv; /* Command to be executed by child, with args */
762 int pipe_fd[2]; /* Pipe used to synchronize parent and child */
770 fprintf(stderr, "Usage: %s [options] cmd [arg...]\\n\\n", pname);
771 fprintf(stderr, "Create a child process that executes a shell "
772 "command in a new user namespace,\\n"
773 "and possibly also other new namespace(s).\\n\\n");
774 fprintf(stderr, "Options can be:\\n\\n");
775 #define fpe(str) fprintf(stderr, " %s", str);
776 fpe("\-i New IPC namespace\\n");
777 fpe("\-m New mount namespace\\n");
778 fpe("\-n New network namespace\\n");
779 fpe("\-p New PID namespace\\n");
780 fpe("\-u New UTS namespace\\n");
781 fpe("\-U New user namespace\\n");
782 fpe("\-M uid_map Specify UID map for user namespace\\n");
783 fpe("\-G gid_map Specify GID map for user namespace\\n");
784 fpe("\-z Map user\(aqs UID and GID to 0 in user namespace\\n");
785 fpe(" (equivalent to: \-M \(aq0 <uid> 1\(aq \-G \(aq0 <gid> 1\(aq)\\n");
786 fpe("\-v Display verbose messages\\n");
788 fpe("If \-z, \-M, or \-G is specified, \-U is required.\\n");
789 fpe("It is not permitted to specify both \-z and either \-M or \-G.\\n");
791 fpe("Map strings for \-M and \-G consist of records of the form:\\n");
793 fpe(" ID\-inside\-ns ID\-outside\-ns len\\n");
795 fpe("A map string can contain multiple records, separated"
797 fpe("the commas are replaced by newlines before writing"
798 " to map files.\\n");
803 /* Update the mapping file \(aqmap_file\(aq, with the value provided in
804 \(aqmapping\(aq, a string that defines a UID or GID mapping. A UID or
805 GID mapping consists of one or more newline\-delimited records
808 ID_inside\-ns ID\-outside\-ns length
810 Requiring the user to supply a string that contains newlines is
811 of course inconvenient for command\-line use. Thus, we permit the
812 use of commas to delimit records in this string, and replace them
813 with newlines before writing the string to the file. */
816 update_map(char *mapping, char *map_file)
819 size_t map_len; /* Length of \(aqmapping\(aq */
821 /* Replace commas in mapping string with newlines */
823 map_len = strlen(mapping);
824 for (j = 0; j < map_len; j++)
825 if (mapping[j] == \(aq,\(aq)
826 mapping[j] = \(aq\\n\(aq;
828 fd = open(map_file, O_RDWR);
830 fprintf(stderr, "ERROR: open %s: %s\\n", map_file,
835 if (write(fd, mapping, map_len) != map_len) {
836 fprintf(stderr, "ERROR: write %s: %s\\n", map_file,
844 static int /* Start function for cloned child */
847 struct child_args *args = (struct child_args *) arg;
850 /* Wait until the parent has updated the UID and GID mappings.
851 See the comment in main(). We wait for end of file on a
852 pipe that will be closed by the parent process once it has
853 updated the mappings. */
855 close(args\->pipe_fd[1]); /* Close our descriptor for the write
856 end of the pipe so that we see EOF
857 when parent closes its descriptor */
858 if (read(args\->pipe_fd[0], &ch, 1) != 0) {
860 "Failure in child: read from pipe returned != 0\\n");
864 /* Execute a shell command */
866 printf("About to exec %s\\n", args\->argv[0]);
867 execvp(args\->argv[0], args\->argv);
871 #define STACK_SIZE (1024 * 1024)
873 static char child_stack[STACK_SIZE]; /* Space for child\(aqs stack */
876 main(int argc, char *argv[])
878 int flags, opt, map_zero;
880 struct child_args args;
881 char *uid_map, *gid_map;
882 const int MAP_BUF_SIZE = 100;
883 char map_buf[MAP_BUF_SIZE];
884 char map_path[PATH_MAX];
886 /* Parse command\-line options. The initial \(aq+\(aq character in
887 the final getopt() argument prevents GNU\-style permutation
888 of command\-line options. That\(aqs useful, since sometimes
889 the \(aqcommand\(aq to be executed by this program itself
890 has command\-line options. We don\(aqt want getopt() to treat
891 those as options to this program. */
898 while ((opt = getopt(argc, argv, "+imnpuUM:G:zv")) != \-1) {
900 case \(aqi\(aq: flags |= CLONE_NEWIPC; break;
901 case \(aqm\(aq: flags |= CLONE_NEWNS; break;
902 case \(aqn\(aq: flags |= CLONE_NEWNET; break;
903 case \(aqp\(aq: flags |= CLONE_NEWPID; break;
904 case \(aqu\(aq: flags |= CLONE_NEWUTS; break;
905 case \(aqv\(aq: verbose = 1; break;
906 case \(aqz\(aq: map_zero = 1; break;
907 case \(aqM\(aq: uid_map = optarg; break;
908 case \(aqG\(aq: gid_map = optarg; break;
909 case \(aqU\(aq: flags |= CLONE_NEWUSER; break;
910 default: usage(argv[0]);
914 /* \-M or \-G without \-U is nonsensical */
916 if (((uid_map != NULL || gid_map != NULL || map_zero) &&
917 !(flags & CLONE_NEWUSER)) ||
918 (map_zero && (uid_map != NULL || gid_map != NULL)))
921 args.argv = &argv[optind];
923 /* We use a pipe to synchronize the parent and child, in order to
924 ensure that the parent sets the UID and GID maps before the child
925 calls execve(). This ensures that the child maintains its
926 capabilities during the execve() in the common case where we
927 want to map the child\(aqs effective user ID to 0 in the new user
928 namespace. Without this synchronization, the child would lose
929 its capabilities if it performed an execve() with nonzero
930 user IDs (see the capabilities(7) man page for details of the
931 transformation of a process\(aqs capabilities during execve()). */
933 if (pipe(args.pipe_fd) == \-1)
936 /* Create the child in new namespace(s) */
938 child_pid = clone(childFunc, child_stack + STACK_SIZE,
939 flags | SIGCHLD, &args);
940 if (child_pid == \-1)
943 /* Parent falls through to here */
946 printf("%s: PID of child created by clone() is %ld\\n",
947 argv[0], (long) child_pid);
949 /* Update the UID and GID maps in the child */
951 if (uid_map != NULL || map_zero) {
952 snprintf(map_path, PATH_MAX, "/proc/%ld/uid_map",
955 snprintf(map_buf, MAP_BUF_SIZE, "0 %ld 1", (long) getuid());
958 update_map(uid_map, map_path);
960 if (gid_map != NULL || map_zero) {
961 snprintf(map_path, PATH_MAX, "/proc/%ld/gid_map",
964 snprintf(map_buf, MAP_BUF_SIZE, "0 %ld 1", (long) getgid());
967 update_map(gid_map, map_path);
970 /* Close the write end of the pipe, to signal to the child that we
971 have updated the UID and GID maps */
973 close(args.pipe_fd[1]);
975 if (waitpid(child_pid, NULL, 0) == \-1) /* Wait for child */
979 printf("%s: terminating\\n", argv[0]);
985 .BR newgidmap (1), \" From the shadow package
986 .BR newuidmap (1), \" From the shadow package
991 .BR subgid (5), \" From the shadow package
992 .BR subuid (5), \" From the shadow package
994 .BR capabilities (7),
996 .BR pid_namespaces (7)
998 The kernel source file
999 .IR Documentation/namespaces/resource-control.txt .