This adds support for the "nosymfollow" mount option, which indicates
that symlinks should not be traversed on the mount this option is
applied to. Also update the mount(8) man page with information about
this option.
Signed-off-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Ross Zwisler <zwisler@google.com>
Fix couple "initialization of ‘long int’ from ‘void *’ makes integer from
pointer without a cast" warnings.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
This workaround has been introduced by
e4925f591c
And originally requested by https://github.com/systemd/systemd/issues/10872
It seems we do not need it anymore as the problem should be fixed in kernel since 5.8
(kernel commit 9f6c61f96f2d97cbb5f7fa85607bc398f843ff0f).
Note that the libmount solution is very expensive as it repeats read()
many times (until we get consistent result) if kernel is busy with
mount table modification. This behaviour makes events management in
systemd (or other places) pretty difficult as read mountinfo takes
time on busy systems.
Addresses: https://github.com/systemd/systemd/pull/16537
Signed-off-by: Karel Zak <kzak@redhat.com>
It seems to be failing with
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==13==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000055f428 bp 0x7ffc3743a170 sp 0x7ffc3743a080 T0)
==13==The signal is caused by a WRITE memory access.
==13==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x55f428 in mnt_table_parse_next /src/util-linux/libmount/src/tab_parse.c:587:6
#1 0x55c200 in __table_parse_stream /src/util-linux/libmount/src/tab_parse.c:737:8
#2 0x55be38 in mnt_table_parse_stream /src/util-linux/libmount/src/tab_parse.c:809:8
#3 0x5511ff in LLVMFuzzerTestOneInput /src/util-linux/libmount/src/fuzz.c:21:16
#4 0x458a31 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:558:15
#5 0x458175 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
#6 0x45a117 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:770:7
#7 0x45a319 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:799:3
#8 0x44a055 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:846:6
#9 0x471bf2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
#10 0x7fe3bd93b83f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
#11 0x41f208 in _start (/out/test_mount_fuzz+0x41f208)
DEDUP_TOKEN: mnt_table_parse_next--__table_parse_stream--mnt_table_parse_stream
```
The fuzzer is supposed to cover `mnt_table_parse_stream`, which is
used by systemd to parse /proc/self/mountinfo. The systemd project
has run into memory leaks there at least twice:
https://github.com/systemd/systemd/pull/12252#issuecomment-482804040https://github.com/systemd/systemd/issues/8504
so it seems to be a good idea to continuously fuzz that particular
function.
The patch can be tested locally by installing clang and running
./tools/oss-fuzz.sh. Currently the fuzzer is failing with
```
=================================================================
==96638==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 216 byte(s) in 1 object(s) allocated from:
#0 0x50cd77 in calloc (/home/vagrant/util-linux/out/test_mount_fuzz+0x50cd77)
#1 0x58716a in mnt_new_fs /home/vagrant/util-linux/libmount/src/fs.c:36:25
#2 0x54f224 in __table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:728:9
#3 0x54eed8 in mnt_table_parse_stream /home/vagrant/util-linux/libmount/src/tab_parse.c:804:8
#4 0x5448b2 in LLVMFuzzerTestOneInput /home/vagrant/util-linux/libmount/src/fuzz.c:19:16
#5 0x44cc88 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44cc88)
#6 0x44d8b0 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) (/home/vagrant/util-linux/out/test_mount_fuzz+0x44d8b0)
#7 0x44e270 in fuzzer::Fuzzer::MutateAndTestOne() (/home/vagrant/util-linux/out/test_mount_fuzz+0x44e270)
#8 0x450617 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) (/home/vagrant/util-linux/out/test_mount_fuzz+0x450617)
#9 0x43adbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/util-linux/out/test_mount_fuzz+0x43adbb)
#10 0x42ad46 in main (/home/vagrant/util-linux/out/test_mount_fuzz+0x42ad46)
#11 0x7fa084f621a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
SUMMARY: AddressSanitizer: 216 byte(s) leaked in 1 allocation(s).
INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.
```
Once the bug is fixed and the OSS-Fuzz counterpart is merged it should be possible
to turn on CIFuzz to make sure the fuzz target can be built and run for some time
without crashing: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
Signed-off-by: Evgeny Vereshchagin <evvers@ya.ru>
It's not necessary to initialize a crypt_device, the function will do it
on its own if NULL is passed. Removes a few extra library calls.
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
Allows logs from the library to be printed by our system:
731814: libmount: VERITY: crypsetup: Device libmnt_img.raw already exists.
If the mount context is in verbose mode, enable all debug logs from
libcrypsetup as well.
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
Enabling libcrypsetup in libmount had several unintended side
effects.
First of all, it increases the Debian minimal image size by
~2.5% (5.6MB worth of new libraries).
Then, due to libcryptsetup linkage to OpenSSL and libjson-c,
it causes incompatibilities with external programs linking
against both libmount and a private, static, old version of
OpenSSL, or external programs linking against libjansson or
json-glib, which have one symbol in common with libjson-c.
If ./configure is ran with --with-crypsetup=dlopen,
instead of linking to libcrypsetup, use dlopen to resolve
the symbols at runtime only when the verity feature is
used, thus avoiding clashes and keeping images size down.
Fixes#1081
Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>
Let's simplify the loop where we add FS to the table. The optimization
for recoverable errors is a fragile overkill. The new code always
allocates and unrefs FS for each loop.
Addresses: https://github.com/karelzak/util-linux/pull/1068
Signed-off-by: Karel Zak <kzak@redhat.com>
This patch add support for a new tag. The tag is based on udev block
device ID (see /dev/disk/by-id). The usual use-case is to use
WWN for this purpose, for example
# mount ID=wwn-0x50026b724b09a1ff /mnt
Note that ID is not strictly defined and udevd generates various IDs
also for HW where WWN is undefined. This is reason why introduce ID=
seems better and more generic than more restrictive WWN=.
Addresses: https://github.com/karelzak/util-linux/issues/1008
Signed-off-by: Karel Zak <kzak@redhat.com>
fstab:
//rhel73/myshare/sub/path /mnt cifs
after mount in mountinfo:
# grep cifs /proc/self/mountinfo
47 39 0:40 /sub/path /mnt rw,relatime shared:60 - cifs //rhel73/myshare/sub/path ...
^^^^^^^^^
or:
# grep cifs /proc/self/mountinfo
47 39 0:40 / /mnt rw,relatime shared:60 - cifs //rhel73/myshare/sub/path ...
^
That is so since on kernel cifs code, cifs_get_root (which returns the
entry associated with mnt_root) return s_root if
CIFS_MOUNT_USE_PREFIX_PATH is set, no questions asked.
This situation can occurr often on CIFS mounts, as CIFS servers limit
frequently scope of access to the root path.
[kzak@redhat.com: - add more info to the commit message,
- clean up variable names]
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1826719
Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Before ecfeae90a2 ("libmount: Ensure utab.lock mode 644"), you could do
something like:
irc:/tmp umount --version
umount from util-linux 2.27.1 (libmount 2.27.0: selinux, assert, debug)
irc:/tmp mkdir foo bar
irc:/tmp unshare -Urm
irc:/tmp mount --bind foo bar
irc:/tmp umount bar
irc:/tmp echo $?
0
However, afterwards, you get:
/tmp unshare -Urm
/tmp mount --bind foo bar
/tmp umount bar
umount: /tmp/bar: filesystem was unmounted, but failed to update userspace mount table.
Because of the chmod failing:
fchmod(3, 0644) = -1 EPERM (Operation not permitted)
Let's figure out whether the chmod is necessary before doing it, and only
do it if it is necessary. This won't fix cases where the system is already
broken, but at least on healthy systems umount will behave as before.
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
* 'clang' of https://github.com/neheb/util-linux:
[clang-tidy] fix misleading identation
[clang-tidy] use ceil
[clang-tidy] fix wrong *cmp usage
[clang-tidy] do not use else after return
[clang-tidy] do not return in void functions
[clang-tidy] fix mismatching declarations
Currently, umount /foo results in a statfs("/foo") call, which triggers
autofs. This can create another mountpoint on /foo, which is then unmounted
later instead of the actual /foo at the time umount was called.
This is especially an issue for umount -R /bar, which just fails with
-EBUSY as the accidental mountpoint is never accounted for and so it tries
to umount /bar before /bar/someautofs.
Replace the direct statfs call with open(path, O_PATH) + fstatfs, which sees
the autofs mount directly, without triggering it.
The classic mount(8) behavior is to try read-only on write-protected devices
if the first mount syscall attempt ends with EACCES.
It seems we can implement this feature also for EBUSY if the same mount source
is already mounted with "ro" superblock option.
The typical use-case is iso image (always read-only) mounted on two places.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1809124
Signed-off-by: Karel Zak <kzak@redhat.com>
libmount returns EPERM for all X- and x- mount options for non-root
users when evaluate X-mount.mkdir. It's bug, we need to be sensitive
to only X-mount.mkdir and only if the target directory is missing.
Addresses: https://github.com/karelzak/util-linux/issues/941
Signed-off-by: Karel Zak <kzak@redhat.com>
A new API was added to libcryptsetup to make use of the kernel's new
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG feature, which allows to sign
root hashes. Add a verity.roothashsig option to use it.
Device reuse will be allowed only if signatures are used by all, or
by none.
Since v2.35 mount(8) drops suid on -EPERM and repeat necessary actions
before mount(2) syscall. This patch also improves this behavior for
X-mount.mkdir too.
mount(8):
* return -EPERM on sanitize_paths() rather than call err()
* call suid_drop() on failed sanitize_paths()
* update man page
libmount:
* mnt_context_prepare_target() refactoring
* return -EPERM when in restricted mode for X-mount.mkdir
Fixed version:
/home/kzak/mnt-foo sr.net.home:/home/kzak fuse.sshfs noauto,X-mount.mkdir
$ mount /home/kzak/mnt-foo
kzak@sr.net.home's password:
$ /home/projects/util-linux/util-linux findmnt /home/kzak/mnt-foo
TARGET SOURCE FSTYPE OPTIONS
/home/kzak/mnt-foo sr.net.home:/home/kzak fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
Addresses: https://github.com/systemd/systemd/issues/14418
Signed-off-by: Karel Zak <kzak@redhat.com>
Allow users to point mount to a file to read the roothash, in addition
to passing it inline.
Allows a volume managed by a systemd mount unit to be updated without
changing the mount unit content itself, for easier and more user friendly
servicing.
The following new options are added:
verity.hashdevice
verity.roothash
verity.hashoffset
The source path will be used as a dm-verity object, and will be
opened using libcryptsetup APIs.
A new --with-cryptsetup build-time option is added, which adds a
dependency on libcryptsetup. To ease bootstrapping, given libcryptsetup
build-depends on util-linux for libuuid, if --with-cryptsetup=yes but
libcryptsetup is not installed only a warning will be printed at
configure time rather than an error. This way stage0/first stage/ring0
builds can use the same configure options but avoid installing
cryptsetup to get a working base set, and then rebuild util-linux in
the next step of the boostrapping process.
If verity options are selected but cannot be fullfilled due to lack of
dependencies, mounting a volume will fail even if using a loop device
would work as a fallback, to avoid silently skipping integrity checks.
Mattias Nissler
Sami Kerola
Karel Zak
Evgeny Vereshchagin
Luca Boccassi
Yuri Chornoivan
Gabriel de Perthuis
Roberto Bergantinos Corpas
Tycho Andersen
Rosen Penev
Fabian Vogt