1MOUNT_SETATTR(2)           Linux Programmer's Manual          MOUNT_SETATTR(2)
2
3
4

NAME

6       mount_setattr - change properties of a mount or mount tree
7

SYNOPSIS

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

DESCRIPTION

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

RETURN VALUE

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

ERRORS

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

VERSIONS

329       mount_setattr() first appeared in Linux 5.12.
330

CONFORMING TO

332       mount_setattr() is Linux-specific.
333

NOTES

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
349security.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
353system.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

EXAMPLES

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

SEE ALSO

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

COLOPHON

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)
Impressum