1MOUNT_SETATTR(2) Linux Programmer's Manual MOUNT_SETATTR(2)
2
3
4
6 mount_setattr - change properties of a mount or mount tree
7
9 #include <linux/fcntl.h> /* Definition of AT_* constants */
10 #include <linux/mount.h> /* Definition of MOUNT_ATTR_* constants */
11 #include <sys/syscall.h> /* Definition of SYS_* constants */
12 #include <unistd.h>
13
14 int syscall(SYS_mount_setattr, int dirfd, const char *pathname,
15 unsigned int flags, struct mount_attr *attr, size_t size);
16
17 Note: glibc provides no wrapper for mount_setattr(), necessitating the
18 use of syscall(2).
19
21 The mount_setattr() system call changes the mount properties of a mount
22 or an entire mount tree. If pathname is a relative pathname, then it
23 is interpreted relative to the directory referred to by the file de‐
24 scriptor dirfd. If dirfd is the special value AT_FDCWD, then pathname
25 is interpreted relative to the current working directory of the calling
26 process. If pathname is the empty string and AT_EMPTY_PATH is speci‐
27 fied in flags, then the mount properties of the mount identified by
28 dirfd are changed. (See openat(2) for an explanation of why the dirfd
29 argument is useful.)
30
31 The mount_setattr() system call uses an extensible structure (struct
32 mount_attr) to allow for future extensions. Any non-flag extensions to
33 mount_setattr() will be implemented as new fields appended to the this
34 structure, with a zero value in a new field resulting in the kernel be‐
35 having as though that extension field was not present. Therefore, the
36 caller must zero-fill this structure on initialization. See the "Ex‐
37 tensibility" subsection under NOTES for more details.
38
39 The size argument should usually be specified as sizeof(struct
40 mount_attr). However, if the caller is using a kernel that supports an
41 extended struct mount_attr, but the caller does not intend to make use
42 of these features, it is possible to pass the size of an earlier ver‐
43 sion of the structure together with the extended structure. This al‐
44 lows the kernel to not copy later parts of the structure that aren't
45 used anyway. With each extension that changes the size of struct
46 mount_attr, the kernel will expose a definition of the form
47 MOUNT_ATTR_SIZE_VERnumber. For example, the macro for the size of the
48 initial version of struct mount_attr is MOUNT_ATTR_SIZE_VER0.
49
50 The flags argument can be used to alter the pathname resolution behav‐
51 ior. The supported values are:
52
53 AT_EMPTY_PATH
54 If pathname is the empty string, change the mount properties on
55 dirfd itself.
56
57 AT_RECURSIVE
58 Change the mount properties of the entire mount tree.
59
60 AT_SYMLINK_NOFOLLOW
61 Don't follow trailing symbolic links.
62
63 AT_NO_AUTOMOUNT
64 Don't trigger automounts.
65
66 The attr argument of mount_setattr() is a structure of the following
67 form:
68
69 struct mount_attr {
70 __u64 attr_set; /* Mount properties to set */
71 __u64 attr_clr; /* Mount properties to clear */
72 __u64 propagation; /* Mount propagation type */
73 __u64 userns_fd; /* User namespace file descriptor */
74 };
75
76 The attr_set and attr_clr members are used to specify the mount proper‐
77 ties that are supposed to be set or cleared for a mount or mount tree.
78 Flags set in attr_set enable a property on a mount or mount tree, and
79 flags set in attr_clr remove a property from a mount or mount tree.
80
81 When changing mount properties, the kernel will first clear the flags
82 specified in the attr_clr field, and then set the flags specified in
83 the attr_set field. For example, these settings:
84
85 struct mount_attr attr = {
86 .attr_clr = MOUNT_ATTR_NOEXEC | MOUNT_ATTR_NODEV,
87 .attr_set = MOUNT_ATTR_RDONLY | MOUNT_ATTR_NOSUID,
88 };
89
90 are equivalent to the following steps:
91
92 unsigned int current_mnt_flags = mnt->mnt_flags;
93
94 /*
95 * Clear all flags set in .attr_clr,
96 * clearing MOUNT_ATTR_NOEXEC and MOUNT_ATTR_NODEV.
97 */
98 current_mnt_flags &= ~attr->attr_clr;
99
100 /*
101 * Now set all flags set in .attr_set,
102 * applying MOUNT_ATTR_RDONLY and MOUNT_ATTR_NOSUID.
103 */
104 current_mnt_flags |= attr->attr_set;
105
106 mnt->mnt_flags = current_mnt_flags;
107
108 As a result of this change, the mount or mount tree (a) is read-only;
109 (b) blocks the execution of set-user-ID and set-group-ID programs; (c)
110 allows execution of programs; and (d) allows access to devices.
111
112 Multiple changes with the same set of flags requested in attr_clr and
113 attr_set are guaranteed to be idempotent after the changes have been
114 applied.
115
116 The following mount attributes can be specified in the attr_set or
117 attr_clr fields:
118
119 MOUNT_ATTR_RDONLY
120 If set in attr_set, makes the mount read-only. If set in
121 attr_clr, removes the read-only setting if set on the mount.
122
123 MOUNT_ATTR_NOSUID
124 If set in attr_set, causes the mount not to honor the set-user-
125 ID and set-group-ID mode bits and file capabilities when execut‐
126 ing programs. If set in attr_clr, clears the set-user-ID, set-
127 group-ID, and file capability restriction if set on this mount.
128
129 MOUNT_ATTR_NODEV
130 If set in attr_set, prevents access to devices on this mount.
131 If set in attr_clr, removes the restriction that prevented ac‐
132 cessing devices on this mount.
133
134 MOUNT_ATTR_NOEXEC
135 If set in attr_set, prevents executing programs on this mount.
136 If set in attr_clr, removes the restriction that prevented exe‐
137 cuting programs on this mount.
138
139 MOUNT_ATTR_NOSYMFOLLOW
140 If set in attr_set, prevents following symbolic links on this
141 mount. If set in attr_clr, removes the restriction that pre‐
142 vented following symbolic links on this mount.
143
144 MOUNT_ATTR_NODIRATIME
145 If set in attr_set, prevents updating access time for directo‐
146 ries on this mount. If set in attr_clr, removes the restriction
147 that prevented updating access time for directories. Note that
148 MOUNT_ATTR_NODIRATIME can be combined with other access-time
149 settings and is implied by the noatime setting. All other ac‐
150 cess-time settings are mutually exclusive.
151
152 MOUNT_ATTR__ATIME - changing access-time settings
153 The access-time values listed below are an enumeration that in‐
154 cludes the value zero, expressed in the bits defined by the mask
155 MOUNT_ATTR__ATIME. Even though these bits are an enumeration
156 (in contrast to the other mount flags such as
157 MOUNT_ATTR_NOEXEC), they are nonetheless passed in attr_set and
158 attr_clr for consistency with fsmount(2), which introduced this
159 behavior.
160
161 Note that, since the access-time values are an enumeration
162 rather than bit values, a caller wanting to transition to a dif‐
163 ferent access-time setting cannot simply specify the access-time
164 setting in attr_set, but must also include MOUNT_ATTR__ATIME in
165 the attr_clr field. The kernel will verify that
166 MOUNT_ATTR__ATIME isn't partially set in attr_clr (i.e., either
167 all bits in the MOUNT_ATTR__ATIME bit field are either set or
168 clear), and that attr_set doesn't have any access-time bits set
169 if MOUNT_ATTR__ATIME isn't set in attr_clr.
170
171 MOUNT_ATTR_RELATIME
172 When a file is accessed via this mount, update the file's
173 last access time (atime) only if the current value of
174 atime is less than or equal to the file's last modifica‐
175 tion time (mtime) or last status change time (ctime).
176
177 To enable this access-time setting on a mount or mount
178 tree, MOUNT_ATTR_RELATIME must be set in attr_set and
179 MOUNT_ATTR__ATIME must be set in the attr_clr field.
180
181 MOUNT_ATTR_NOATIME
182 Do not update access times for (all types of) files on
183 this mount.
184
185 To enable this access-time setting on a mount or mount
186 tree, MOUNT_ATTR_NOATIME must be set in attr_set and
187 MOUNT_ATTR__ATIME must be set in the attr_clr field.
188
189 MOUNT_ATTR_STRICTATIME
190 Always update the last access time (atime) when files are
191 accessed on this mount.
192
193 To enable this access-time setting on a mount or mount
194 tree, MOUNT_ATTR_STRICTATIME must be set in attr_set and
195 MOUNT_ATTR__ATIME must be set in the attr_clr field.
196
197 MOUNT_ATTR_IDMAP
198 If set in attr_set, creates an ID-mapped mount. The ID mapping
199 is taken from the user namespace specified in userns_fd and at‐
200 tached to the mount.
201
202 Since it is not supported to change the ID mapping of a mount
203 after it has been ID mapped, it is invalid to specify
204 MOUNT_ATTR_IDMAP in attr_clr.
205
206 For further details, see the subsection "ID-mapped mounts" under
207 NOTES.
208
209 The propagation field is used to specify the propagation type of the
210 mount or mount tree. This field either has the value zero, meaning
211 leave the propagation type unchanged, or it has one of the following
212 values:
213
214 MS_PRIVATE
215 Turn all mounts into private mounts.
216
217 MS_SHARED
218 Turn all mounts into shared mounts.
219
220 MS_SLAVE
221 Turn all mounts into dependent mounts.
222
223 MS_UNBINDABLE
224 Turn all mounts into unbindable mounts.
225
226 For further details on the above propagation types, see mount_name‐
227 spaces(7).
228
230 On success, mount_setattr() returns zero. On error, -1 is returned and
231 errno is set to indicate the cause of the error.
232
234 EBADF pathname is relative but dirfd is neither AT_FDCWD nor a valid
235 file descriptor.
236
237 EBADF userns_fd is not a valid file descriptor.
238
239 EBUSY The caller tried to change the mount to MOUNT_ATTR_RDONLY, but
240 the mount still holds files open for writing.
241
242 EINVAL The pathname specified via the dirfd and pathname arguments to
243 mount_setattr() isn't a mount point.
244
245 EINVAL An unsupported value was set in flags.
246
247 EINVAL An unsupported value was specified in the attr_set field of
248 mount_attr.
249
250 EINVAL An unsupported value was specified in the attr_clr field of
251 mount_attr.
252
253 EINVAL An unsupported value was specified in the propagation field of
254 mount_attr.
255
256 EINVAL More than one of MS_SHARED, MS_SLAVE, MS_PRIVATE, or MS_UNBIND‐
257 ABLE was set in the propagation field of mount_attr.
258
259 EINVAL An access-time setting was specified in the attr_set field with‐
260 out MOUNT_ATTR__ATIME being set in the attr_clr field.
261
262 EINVAL MOUNT_ATTR_IDMAP was specified in attr_clr.
263
264 EINVAL A file descriptor value was specified in userns_fd which exceeds
265 INT_MAX.
266
267 EINVAL A valid file descriptor value was specified in userns_fd, but
268 the file descriptor did not refer to a user namespace.
269
270 EINVAL The underlying filesystem does not support ID-mapped mounts.
271
272 EINVAL The mount that is to be ID mapped is not a detached mount; that
273 is, the mount has not previously been visible in a mount name‐
274 space.
275
276 EINVAL A partial access-time setting was specified in attr_clr instead
277 of MOUNT_ATTR__ATIME being set.
278
279 EINVAL The mount is located outside the caller's mount namespace.
280
281 EINVAL The underlying filesystem has been mounted in a mount namespace
282 that is owned by a noninitial user namespace
283
284 ENOENT A pathname was empty or had a nonexistent component.
285
286 ENOMEM When changing mount propagation to MS_SHARED, a new peer group
287 ID needs to be allocated for all mounts without a peer group ID
288 set. This allocation failed because there was not enough memory
289 to allocate the relevant internal structures.
290
291 ENOSPC When changing mount propagation to MS_SHARED, a new peer group
292 ID needs to be allocated for all mounts without a peer group ID
293 set. This allocation failed because the kernel has run out of
294 IDs.
295
296 EPERM One of the mounts had at least one of MOUNT_ATTR_NOATIME,
297 MOUNT_ATTR_NODEV, MOUNT_ATTR_NODIRATIME, MOUNT_ATTR_NOEXEC,
298 MOUNT_ATTR_NOSUID, or MOUNT_ATTR_RDONLY set and the flag is
299 locked. Mount attributes become locked on a mount if:
300
301 • A new mount or mount tree is created causing mount propaga‐
302 tion across user namespaces (i.e., propagation to a mount
303 namespace owned by a different user namespace). The kernel
304 will lock the aforementioned flags to prevent these sensitive
305 properties from being altered.
306
307 • A new mount and user namespace pair is created. This happens
308 for example when specifying CLONE_NEWUSER | CLONE_NEWNS in
309 unshare(2), clone(2), or clone3(2). The aforementioned flags
310 become locked in the new mount namespace to prevent sensitive
311 mount properties from being altered. Since the newly created
312 mount namespace will be owned by the newly created user name‐
313 space, a calling process that is privileged in the new user
314 namespace would—in the absence of such locking—be able to al‐
315 ter sensitive mount properties (e.g., to remount a mount that
316 was marked read-only as read-write in the new mount name‐
317 space).
318
319 EPERM A valid file descriptor value was specified in userns_fd, but
320 the file descriptor refers to the initial user namespace.
321
322 EPERM An attempt was made to add an ID mapping to a mount that is al‐
323 ready ID mapped.
324
325 EPERM The caller does not have CAP_SYS_ADMIN in the initial user name‐
326 space.
327
329 mount_setattr() first appeared in Linux 5.12.
330
332 mount_setattr() is Linux-specific.
333
335 ID-mapped mounts
336 Creating an ID-mapped mount makes it possible to change the ownership
337 of all files located under a mount. Thus, ID-mapped mounts make it
338 possible to change ownership in a temporary and localized way. It is a
339 localized change because the ownership changes are visible only via a
340 specific mount. All other users and locations where the filesystem is
341 exposed are unaffected. It is a temporary change because the ownership
342 changes are tied to the lifetime of the mount.
343
344 Whenever callers interact with the filesystem through an ID-mapped
345 mount, the ID mapping of the mount will be applied to user and group
346 IDs associated with filesystem objects. This encompasses the user and
347 group IDs associated with inodes and also the following xattr(7) keys:
348
349 • security.capability, whenever filesystem capabilities are stored or
350 returned in the VFS_CAP_REVISION_3 format, which stores a root user
351 ID alongside the capabilities (see capabilities(7)).
352
353 • system.posix_acl_access and system.posix_acl_default, whenever user
354 IDs or group IDs are stored in ACL_USER or ACL_GROUP entries.
355
356 The following conditions must be met in order to create an ID-mapped
357 mount:
358
359 • The caller must have the CAP_SYS_ADMIN capability in the initial
360 user namespace.
361
362 • The filesystem must be mounted in a mount namespace that is owned by
363 the initial user namespace.
364
365 • The underlying filesystem must support ID-mapped mounts. Currently,
366 the xfs(5), ext4(5), and FAT filesystems support ID-mapped mounts
367 with more filesystems being actively worked on.
368
369 • The mount must not already be ID-mapped. This also implies that the
370 ID mapping of a mount cannot be altered.
371
372 • The mount must be a detached mount; that is, it must have been cre‐
373 ated by calling open_tree(2) with the OPEN_TREE_CLONE flag and it
374 must not already have been visible in a mount namespace. (To put
375 things another way: the mount must not have been attached to the
376 filesystem hierarchy with a system call such as move_mount(2).)
377
378 ID mappings can be created for user IDs, group IDs, and project IDs.
379 An ID mapping is essentially a mapping of a range of user or group IDs
380 into another or the same range of user or group IDs. ID mappings are
381 written to map files as three numbers separated by white space. The
382 first two numbers specify the starting user or group ID in each of the
383 two user namespaces. The third number specifies the range of the ID
384 mapping. For example, a mapping for user IDs such as "1000 1001 1"
385 would indicate that user ID 1000 in the caller's user namespace is
386 mapped to user ID 1001 in its ancestor user namespace. Since the map
387 range is 1, only user ID 1000 is mapped.
388
389 It is possible to specify up to 340 ID mappings for each ID mapping
390 type. If any user IDs or group IDs are not mapped, all files owned by
391 that unmapped user or group ID will appear as being owned by the over‐
392 flow user ID or overflow group ID respectively.
393
394 Further details on setting up ID mappings can be found in user_name‐
395 spaces(7).
396
397 In the common case, the user namespace passed in userns_fd (together
398 with MOUNT_ATTR_IDMAP in attr_set) to create an ID-mapped mount will be
399 the user namespace of a container. In other scenarios it will be a
400 dedicated user namespace associated with a user's login session as is
401 the case for portable home directories in systemd-homed.service(8)).
402 It is also perfectly fine to create a dedicated user namespace for the
403 sake of ID mapping a mount.
404
405 ID-mapped mounts can be useful in the following and a variety of other
406 scenarios:
407
408 • Sharing files or filesystems between multiple users or multiple ma‐
409 chines, especially in complex scenarios. For example, ID-mapped
410 mounts are used to implement portable home directories in systemd-
411 homed.service(8), where they allow users to move their home direc‐
412 tory to an external storage device and use it on multiple computers
413 where they are assigned different user IDs and group IDs. This ef‐
414 fectively makes it possible to assign random user IDs and group IDs
415 at login time.
416
417 • Sharing files or filesystems from the host with unprivileged con‐
418 tainers. This allows a user to avoid having to change ownership
419 permanently through chown(2).
420
421 • ID mapping a container's root filesystem. Users don't need to
422 change ownership permanently through chown(2). Especially for large
423 root filesystems, using chown(2) can be prohibitively expensive.
424
425 • Sharing files or filesystems between containers with non-overlapping
426 ID mappings.
427
428 • Implementing discretionary access (DAC) permission checking for
429 filesystems lacking a concept of ownership.
430
431 • Efficiently changing ownership on a per-mount basis. In contrast to
432 chown(2), changing ownership of large sets of files is instantaneous
433 with ID-mapped mounts. This is especially useful when ownership of
434 an entire root filesystem of a virtual machine or container is to be
435 changed as mentioned above. With ID-mapped mounts, a single
436 mount_setattr() system call will be sufficient to change the owner‐
437 ship of all files.
438
439 • Taking the current ownership into account. ID mappings specify pre‐
440 cisely what a user or group ID is supposed to be mapped to. This
441 contrasts with the chown(2) system call which cannot by itself take
442 the current ownership of the files it changes into account. It sim‐
443 ply changes the ownership to the specified user ID and group ID.
444
445 • Locally and temporarily restricted ownership changes. ID-mapped
446 mounts make it possible to change ownership locally, restricting the
447 ownership changes to specific mounts, and temporarily as the owner‐
448 ship changes only apply as long as the mount exists. By contrast,
449 changing ownership via the chown(2) system call changes the owner‐
450 ship globally and permanently.
451
452 Extensibility
453 In order to allow for future extensibility, mount_setattr() requires
454 the user-space application to specify the size of the mount_attr struc‐
455 ture that it is passing. By providing this information, it is possible
456 for mount_setattr() to provide both forwards- and backwards-compatibil‐
457 ity, with size acting as an implicit version number. (Because new ex‐
458 tension fields will always be appended, the structure size will always
459 increase.) This extensibility design is very similar to other system
460 calls such as perf_setattr(2), perf_event_open(2), clone3(2) and ope‐
461 nat2(2).
462
463 Let usize be the size of the structure as specified by the user-space
464 application, and let ksize be the size of the structure which the ker‐
465 nel supports, then there are three cases to consider:
466
467 • If ksize equals usize, then there is no version mismatch and attr
468 can be used verbatim.
469
470 • If ksize is larger than usize, then there are some extension fields
471 that the kernel supports which the user-space application is unaware
472 of. Because a zero value in any added extension field signifies a
473 no-op, the kernel treats all of the extension fields not provided by
474 the user-space application as having zero values. This provides
475 backwards-compatibility.
476
477 • If ksize is smaller than usize, then there are some extension fields
478 which the user-space application is aware of but which the kernel
479 does not support. Because any extension field must have its zero
480 values signify a no-op, the kernel can safely ignore the unsupported
481 extension fields if they are all zero. If any unsupported extension
482 fields are non-zero, then -1 is returned and errno is set to E2BIG.
483 This provides forwards-compatibility.
484
485 Because the definition of struct mount_attr may change in the future
486 (with new fields being added when system headers are updated), user-
487 space applications should zero-fill struct mount_attr to ensure that
488 recompiling the program with new headers will not result in spurious
489 errors at runtime. The simplest way is to use a designated initial‐
490 izer:
491
492 struct mount_attr attr = {
493 .attr_set = MOUNT_ATTR_RDONLY,
494 .attr_clr = MOUNT_ATTR_NODEV
495 };
496
497 Alternatively, the structure can be zero-filled using memset(3) or sim‐
498 ilar functions:
499
500 struct mount_attr attr;
501 memset(&attr, 0, sizeof(attr));
502 attr.attr_set = MOUNT_ATTR_RDONLY;
503 attr.attr_clr = MOUNT_ATTR_NODEV;
504
505 A user-space application that wishes to determine which extensions the
506 running kernel supports can do so by conducting a binary search on size
507 with a structure which has every byte nonzero (to find the largest
508 value which doesn't produce an error of E2BIG).
509
511 /*
512 * This program allows the caller to create a new detached mount
513 * and set various properties on it.
514 */
515 #define _GNU_SOURCE
516 #include <errno.h>
517 #include <fcntl.h>
518 #include <getopt.h>
519 #include <linux/mount.h>
520 #include <linux/types.h>
521 #include <stdbool.h>
522 #include <stdio.h>
523 #include <stdlib.h>
524 #include <string.h>
525 #include <sys/syscall.h>
526 #include <unistd.h>
527
528 static inline int
529 mount_setattr(int dirfd, const char *pathname, unsigned int flags,
530 struct mount_attr *attr, size_t size)
531 {
532 return syscall(SYS_mount_setattr, dirfd, pathname, flags,
533 attr, size);
534 }
535
536 static inline int
537 open_tree(int dirfd, const char *filename, unsigned int flags)
538 {
539 return syscall(SYS_open_tree, dirfd, filename, flags);
540 }
541
542 static inline int
543 move_mount(int from_dirfd, const char *from_pathname,
544 int to_dirfd, const char *to_pathname, unsigned int flags)
545 {
546 return syscall(SYS_move_mount, from_dirfd, from_pathname,
547 to_dirfd, to_pathname, flags);
548 }
549
550 static const struct option longopts[] = {
551 {"map-mount", required_argument, NULL, 'a'},
552 {"recursive", no_argument, NULL, 'b'},
553 {"read-only", no_argument, NULL, 'c'},
554 {"block-setid", no_argument, NULL, 'd'},
555 {"block-devices", no_argument, NULL, 'e'},
556 {"block-exec", no_argument, NULL, 'f'},
557 {"no-access-time", no_argument, NULL, 'g'},
558 { NULL, 0, NULL, 0 },
559 };
560
561 #define exit_log(format, ...) do \
562 { \
563 fprintf(stderr, format, ##__VA_ARGS__); \
564 exit(EXIT_FAILURE); \
565 } while (0)
566
567 int
568 main(int argc, char *argv[])
569 {
570 struct mount_attr *attr = &(struct mount_attr){};
571 int fd_userns = -1;
572 bool recursive = false;
573 int index = 0;
574 int ret;
575
576 while ((ret = getopt_long_only(argc, argv, "",
577 longopts, &index)) != -1) {
578 switch (ret) {
579 case 'a':
580 fd_userns = open(optarg, O_RDONLY | O_CLOEXEC);
581 if (fd_userns == -1)
582 exit_log("%m - Failed top open %s\n", optarg);
583 break;
584 case 'b':
585 recursive = true;
586 break;
587 case 'c':
588 attr->attr_set |= MOUNT_ATTR_RDONLY;
589 break;
590 case 'd':
591 attr->attr_set |= MOUNT_ATTR_NOSUID;
592 break;
593 case 'e':
594 attr->attr_set |= MOUNT_ATTR_NODEV;
595 break;
596 case 'f':
597 attr->attr_set |= MOUNT_ATTR_NOEXEC;
598 break;
599 case 'g':
600 attr->attr_set |= MOUNT_ATTR_NOATIME;
601 attr->attr_clr |= MOUNT_ATTR__ATIME;
602 break;
603 default:
604 exit_log("Invalid argument specified");
605 }
606 }
607
608 if ((argc - optind) < 2)
609 exit_log("Missing source or target mount point\n");
610
611 const char *source = argv[optind];
612 const char *target = argv[optind + 1];
613
614 /* In the following, -1 as the 'dirfd' argument ensures that
615 open_tree() fails if 'source' is not an absolute pathname. */
616
617 int fd_tree = open_tree(-1, source,
618 OPEN_TREE_CLONE | OPEN_TREE_CLOEXEC |
619 AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0));
620 if (fd_tree == -1)
621 exit_log("%m - Failed to open %s\n", source);
622
623 if (fd_userns >= 0) {
624 attr->attr_set |= MOUNT_ATTR_IDMAP;
625 attr->userns_fd = fd_userns;
626 }
627
628 ret = mount_setattr(fd_tree, "",
629 AT_EMPTY_PATH | (recursive ? AT_RECURSIVE : 0),
630 attr, sizeof(struct mount_attr));
631 if (ret == -1)
632 exit_log("%m - Failed to change mount attributes\n");
633
634 close(fd_userns);
635
636 /* In the following, -1 as the 'to_dirfd' argument ensures that
637 open_tree() fails if 'target' is not an absolute pathname. */
638
639 ret = move_mount(fd_tree, "", -1, target,
640 MOVE_MOUNT_F_EMPTY_PATH);
641 if (ret == -1)
642 exit_log("%m - Failed to attach mount to %s\n", target);
643
644 close(fd_tree);
645
646 exit(EXIT_SUCCESS);
647 }
648
650 newgidmap(1), newuidmap(1), clone(2), mount(2), unshare(2), proc(5),
651 capabilities(7), mount_namespaces(7), user_namespaces(7), xattr(7)
652
654 This page is part of release 5.13 of the Linux man-pages project. A
655 description of the project, information about reporting bugs, and the
656 latest version of this page, can be found at
657 https://www.kernel.org/doc/man-pages/.
658
659
660
661Linux 2021-08-27 MOUNT_SETATTR(2)