Karel Zak [Thu, 6 Oct 2022 10:02:41 +0000 (12:02 +0200)]
libmount: fix mount -a to work with optlist
The original code uses libmnt_fs instance to store mount options. The
new uses libmnt_fs only for library API backward compatibility, but
internally it uses libmnt_optlist. Let's use optlist also to save
context template.
Karel Zak [Tue, 4 Oct 2022 11:05:27 +0000 (13:05 +0200)]
libmount: (legacy) init regualer mount before propagation
We have two ways how mount(2) is used, for propagation-only calls and
regular FS mount. The propagation-only code removes MS_PROPAGATION
flags from main mount options (=optlist), so any later decision about
propagation is impossible. We need to call propagation-only code as
the last thing. (Yes, new FD based mount(8) handles it better.)
Karel Zak [Wed, 21 Sep 2022 15:28:36 +0000 (17:28 +0200)]
libmount: (mount) use independent hooks
It seems better to reuse functions (hooks) to implement various
ways the mount is done. For example, attach to the tree is used
for move, bind, and new mount; set VFS flags is usable for all
operations, etc.
Complete mount(8) is a set (chain) of hooks that is possible to mix to
get the wanted result.
The new API allow for example things like
mount --move /A /B -oro,noexec
because it's
- open_tree()
- mount_setattr()
- move_tree()
Note that the hooks allow extend it to new functionality without core
code modification (for example, X-mount.idmap= append a new hook to
call another mount_setattr()).
Karel Zak [Wed, 21 Sep 2022 09:39:13 +0000 (11:39 +0200)]
libmount: (mount) improve syscalls status handling
The new kernel API is composed from more syscalls, but libmount
originally assumes one syscall and one place where we need to remember
return value of the syscall. It seems the best will be to set the
status after each mount related syscall call (fsopen(), move_mount(),
...) until we reach error or end of mount process.
For better error messages the last failed mount related syscall name
will be recorded in cxt->syscall_name.
Karel Zak [Wed, 21 Sep 2022 09:03:54 +0000 (11:03 +0200)]
libmount: add MS_MOVE to options map
libmount originally had in the options map only options that are
possible to use in fstab. Now we use the map to verify and
classify all mount options, so MS_MOVE is necessary there too.
The patch also add a new MNT_NOFSTAB option flag, not used for now.
Karel Zak [Wed, 24 Aug 2022 14:54:10 +0000 (16:54 +0200)]
libmount: keep context fs and optlist synchronized
The new code uses cxt->optlist to maintain mount options, but for backward
compatibility and for some stuff in the library we need to keep context->fs
up to date with the optlist. It seems the best is to to keep it on-demand
and automatic.
Karel Zak [Thu, 18 Aug 2022 10:04:43 +0000 (12:04 +0200)]
libmount: (mount) de-duplicate when apply MS_SECURE
The options string "users,exec" is "users,nodev,nosuid,noexec,exec",
the option "noexec" is unnecessary here. The last option is the winner
("exec" in this case).
Karel Zak [Thu, 14 Jul 2022 09:00:45 +0000 (11:00 +0200)]
libmount: add mnt_optlist_remove_flags() and mnt_opt_set_external()
- add mnt_optlist_remove_flags() to make it easy to work with flags
- add mnt_opt_set_external() to hidde unnecessary options
- clean up private library header file
Karel Zak [Tue, 28 Jun 2022 08:43:30 +0000 (10:43 +0200)]
libmount: (optlist) support merged optlist
For backward compatibility in mnt_context_* interface we need a way how
to work independently with mount flags and mount options. The library
merges all the options and flags later during mnt_context_prepare_*.
Karel Zak [Fri, 10 Jun 2022 08:24:10 +0000 (10:24 +0200)]
libmount: fix mount hooks use
The function do_mount() is possible to call in loop, for example when
libmount try FS types ("mount -t foo,bar,ext4 /dev/sdc1 /mnt"). In
this case it's bad idea to call in the loop also hooks that do
non-mount operations.
This adds a new mount option X-mount.idmap. This mount option can be
used to create an idmapped mount.
An idmapped mount allows to change ownership of all files located under
a mount according to the ID-mapping associated with a user namespace.
The ownership change is tied to the lifetime and localized to the
relevant mount. The relevant ID-mapping can be specified in two ways:
* A user can specify the ID-mapping directly.
The ID-mapping must be specified using the syntax
id-type:id-mount:id-host:id-range
Specifying "u" as the id-type prefix creates a UID-mapping, "g"
creates a GID-mapping and omitting id-type or specifying "b"
creates both a UID- and GID-mapping.
The id-mount parameter indicates the starting ID in the new mount.
The id-host parameter indicates the starting ID in the filesystem.
The id-range parameter indicates how many IDs are to be mapped.
It is possible to specify multiple ID-mappings.
The individual ID-mappings must be separated by spaces.
For example, the ID-mapping
X-mount.idmap=u:1000:0:1 g:1001:1:2 5000:1000:2
creates an idmapped mount where UID 0 is mapped to UID 1000, GID 1 is
mapped to GUID 1001, GID 2 is mapped to GID 1002, UID and GID 1000 are
mapped to 5000, and UID and GID 1001 are mapped to 5001 in the mount.
When an ID-mapping is specified directly a new user namespace will be
allocated with the requested ID-mapping.
The newly created user namespace will be attached to the mount.
* A user can specify a user namespace file.
The user namespace will then be attached to the mount and the
ID-mapping of the user namespace will become the ID-mapping of the
mount.
For example, *X-mount.idmap=/proc/PID/ns/user* will attach the user
namespace of the process PID to the mount.
Even more details about idmapped mounts can be found in the
mount_setattr(2) manpage of the linux-manpage project.
[kzak@redhat.com: - port Christian's patch to the new libmount hooks API]
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Karel Zak <kzak@redhat.com>