| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The new syscalls (statmount and fd-based mount) are already being
utilized in various areas within the library. Therefore, it would be
more efficient to include the syscalls header file in the private main
library header file.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
The pointed-to structures were const, but the pointers were not.
|
|
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
|
|
Check that linux/mount.h is present before using features that rely on
it.
It is necessary to check for the presence of linux/mount.h explicitly.
Simply relying on the presence of several syscalls (e.g. SYS_move_mount,
SYS_open_tree) does not work reliably, at least not in a cross-compiling
environment.
The syscall definitions are provided by the C library. Meanwhile,
linux/mount.h is provided by the kernel. This opens the possibility for
discrepancies.
A problem arises if the C library (e.g. musl-1.2.3) defines all "mount
fd API" syscalls (and HAVE_MOUNTFD_API becomes true), but the kernel
headers are old enough to not provide linux/mount.h. The resulting error
looks as follows. This example is using an LLVM-13 cross-compiler from
x86_64 to aarch64 with musl-1.2.3 as the C library.
CC libmount/src/la-hooks.lo
In file included from libmount/src/hooks.c:30:
./include/mount-api-utils.h:11:10: fatal error: 'linux/mount.h' file not found
^~~~~~~~~~~~~~~
1 error generated.
make[4]: *** [Makefile:11185: libmount/src/la-hooks.lo] Error 1
To prevent this condition, we add a check to configure that will test
for the presence of linux/mount.h in addition to testing for the mount
fd API. Only if both conditions are met can we actually use the mount
fd API.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
|
|
It was originally designed to play nasty games with /etc/mtab (mount
when /etc is read-only and update later when it's write-able).
The --fake is completely useless with the new API due to complexity
where we cannot skip any step, because the next stuff depends on it.
So, it makes more sense skip all functionality where libmount does
anything significant.
This commit add --fake check to hooks logic to skip all hooks as the
hooks are place where libmount implements mount related invasive
operations (create mountpoint, namespaces, create superblock, move,
mount, etc.).
Frankly, --fake without mtab is useless.
Fixes: https://github.com/util-linux/util-linux/issues/2395
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Don't cleanup if all related to the hooks is already empty.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
* convert selinux contexts to raw format during "prep-options" stage
* convert rootcontext=@target to raw context when final mountpoint
path is available (after mkdir).
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
In some cases we have more hooks in the same stage and it's necessary
to call some hooks after another.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
The final target (mountpoint) depends on others libmount functionality
(X-mount.mkdir or --target-prefix). It means we cannot assume target
when the library calls fix_opts() and translates selinux contexts.
The solution is extra hook executed after mkdir.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
We need to disable support for new kernel API in libmount to test the
old code on new kernels (or maybe also for conservative users).
The new configure option disable only mount(2)-like operations, the
another stuff (like IDs mapping) is not affected.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
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.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
For now it supports -obind and -obind,<flags> operations.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
* initialize only when relevant verity.* options detected
* setup verity device by prepare-source hook
* add post-mount hook to setup deferred deactivation
* deactivate the device on error (when de-initialize the hookset)
* call dlopen/dlclose only once, share symbols between all hooks
* remove verity specific code from rest of libmount
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
It's better to introduce a new stage to call hooks when all is
prepared rather than use MNT_STAGE_PREP_OPTIONS for all cases.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
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>
|
|
* "prepare-options hook" parses {owner,group,mode}= options
* "mount-post hook" calls chmod/own
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
The hookset initialization is unnecessary. It's enough to do the
initialization in the first hook (usually in the "prepare" stage).
This change safes memory and time.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
* "prepare-target hook" checks for X-mount.subdir= and define pre-mount hook
* "mount-pre hook" unshares temporary directory, redirect the next
mount(2) to this temporary directory
* "mount-post hook" binds subdirectory to the final target, umounts
temporary directory
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
Signed-off-by: Karel Zak <kzak@redhat.com>
|
|
* replaces context "addmounts" functionality with more generic hooks
* "hooksets" handles complex functionality by a set of hooks.
During initialization (or later), the hookset can define
arbitrary hook function(s). The library will call the functions from
a specified place ("stage"). Now supported stages are
prepare-options, pre-mount, mount, and post-mount.
This solution looks complex at first glance, but it will help
keep all extensions separated from core library code (IDs mapping,
X-mount.chown/chmod, X-mount.subdir, etc.). It will also be possible to
support multiple implementations for the same functionality (classic
mount(2) vs. new fsmount(2)) without #ifdefs storms etc.
Maybe later we can also use hooksets for external library modules
(like verity support).
* __legacy-mount hookset implements support for the classic mount(2)
syscall. Supported hooks:
prepare-options - analyzes the current setting (libmnt_context)
and setup other hooks when necessary
mount - calls mount(2) for standard "/dev to /mnt" use-cases
post-mount (two possible hooks):
- calls mount(2) to modify propagation flags
- calls mount(2) to implement bind-remount (mount --bind -oro)
Signed-off-by: Karel Zak <kzak@redhat.com>
|
