Unfortunately libtools is not smart enough to link libblkid
dynamically if we link in-tree static libmount.a for libmount tests.
In this case libtools always uses also libblkid.a, but it's problem
for libcryptsetup which requires versioned symbols from libblkid.so
This is no problem for normal binaries, but for libmount tests only
(where we need static library to by-pass public library API).
Signed-off-by: Karel Zak <kzak@redhat.com>
The whole thing is complicated by the fact that we have two layers
of libraries: e.g. libmount also needs libblkid. If we just tell meson
to make libmount static, this is not enough, because we also need it
to link to a static libblkid. Hence in the case of libs that link to
other libs internally, we need to create a different object with a
a different set of link_with items.
To avoid building the libraries twice, libfdisk and libmount are first
built into an internal "convenience" library, which is then linked into
the static and shared versions as appropriate.
To build: meson build && ninja -C build
To run tests: ninja -C build check
To install for packaging: DESTDIR=/var/tmp/inst ninja -C build install
To install for realz: sudo ninja -C build install
v2:
- Optional items are now based on the 'feature' feature in meson.
Built libraries which are disabled turn into disabler() objects
and also poison any executables which link to them.
What is there:
- building of the binaries and libs and the python module
- installation of binaries, libs, python module, localization files,
man pages, pkgconfig files
- running of tests
- most options to configure build equivalently to the
./configure settings
Partially implemented:
- disabling of stuff when things missing. In the C code, the defines
are all used, so that should be fine. In the build system, some
files should be skipped, but that is probably not always done properly.
Getting this right might require some testing of various build option
combinations to get the details right.
Not implemented:
- static builds of fdisk and other binaries
- things marked with XXX or FIXME
- ???
Differences:
- .la files are not created. They are useless and everybody hates them.
- Requires.private in pkgconfig files are not present in the
autogenerated .pc file. Not sure if they should be there or not. If
necessary, they can be added by hand.
- man pages and systemd units are installed by the install target. Not
sure why 'make install' doesn't do that.
- the split between / and /usr is probably wrong. But it's all pointless
anyway, so maybe we could simplify things but not implementing it at
all under meson?
All `eject` tests were failing under ASan, since they call /bin/mount,
which is uninstrumented, but it picks up the instrumented `libblkid`
library, causing ASan to complain:
gcc:
ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
eject: unmount of `/home/runner/work/util-linux/util-linux/tests/output/eject/umount-by-disk-mounted-mnt' failed
clang:
/bin/umount: symbol lookup error: /home/runner/work/util-linux/util-linux/.libs/libblkid.so.1: undefined symbol: __sancov_lowest_stack
eject: unmount of `/home/runner/work/util-linux/util-linux/tests/output/eject/umount-by-disk-mounted-mnt' failed
Subsequently, all tests which require the `scsi_debug` module get skipped,
since it's still in use due to the failed umount:
fdisk: align 512/4K ... SKIPPED (cannot remove scsi_debug module (rmmod))
fdisk: align 512/4K +alignment_offset ... SKIPPED (cannot remove scsi_debug module (rmmod))
fdisk: align 512/4K +MD ... SKIPPED (cannot remove scsi_debug module (rmmod))
In case of gcc this can be easily resolved by setting $LD_PRELOAD to the
respective ASan library. clang makes this a bit more difficult, since it
compiles the ASan library statically, so firstly we need to force dynamic
linking (via -shared-asan), and then add the runtime DSO path to the
linker cache, since it's in a non-standard path.
The command "mount -r" was supported for non-root users in very old
mount(8) versions. Unfortunately, in this case libmount replaces all
mount options from command line by options from fstab. We need
exception for MS_RDONLY.
Fixes: https://github.com/karelzak/util-linux/issues/1235
Signed-off-by: Karel Zak <kzak@redhat.com>
It might be useful for security auditing purposes list all possible
mount flags/options including default set which are normally not listed.
This patch adds "--vfs-all" option to list all fs-independent flags
on VFS-OPTIONS column, as well as libmount funcionality to accomplish
it.
i.e.:
$ findmnt -o VFS-OPTIONS
VFS-OPTIONS
rw,relatime
rw,nosuid,nodev,noexec,relatime
rw,nosuid,nodev,noexec,relatime
ro,nosuid,nodev,noexec
...
$ findmnt --vfs-all -o VFS-OPTIONS
VFS-OPTIONS
rw,exec,suid,dev,async,loud,nomand,atime,noiversion,diratime,relatime,nostrictatime,nolazytime,symfollow
rw,noexec,nosuid,nodev,async,loud,nomand,atime,noiversion,diratime,relatime,nostrictatime,nolazytime,symfollow
rw,noexec,nosuid,nodev,async,loud,nomand,atime,noiversion,diratime,relatime,nostrictatime,nolazytime,symfollow
ro,noexec,nosuid,nodev,async,loud,nomand,atime,noiversion,diratime,norelatime,nostrictatime,nolazytime,symfollow
...
[kzak@redhat.com: - cleanup coding style and comments]
Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
It seems like overkill to provide this #ifdef. For example coreutils
use "char *" for all selinux contexts (since 2014).
Signed-off-by: Karel Zak <kzak@redhat.com>
The function mnt_fs_is_swaparea() does not return TRUE for entries
from /proc/swaps. This is pretty strange.
Signed-off-by: Karel Zak <kzak@redhat.com>
- use robust functions like write_all()
- don't use assert() to check write/open/etc return values, because oss-fuzz.com
report foreign (system, libc, ...) issues as our fails
Addresses: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28009
Signed-off-by: Karel Zak <kzak@redhat.com>
There's a couple of places which use varients on "0x%u" in format strings;
that's almost always wrong - you either want 0x%x or just %u. In libmount's
case it's flags, so I'm assuming the intention really is hex. In the ja.po
case it's %u in the original msgid.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
We append to the options string in loop there. It seems better to use
ul_buffer for this case to avoid duplicate strlen() and reallocs.
Signed-off-by: Karel Zak <kzak@redhat.com>
This function is used by fstab (etc.) parser to split VFS, FS and
userspace options to separate lists. Unfortunately, the current
implementation reallocates the final string always when append a new
option to the string.
The new implementation pre-allocate memory for the final string
according to source string length (1/2 of the original string). This
dramatically reduces realloc() calls.
For example oss-fuzz (./test_mount_fuzz) uses 800K input string, old
version needs 28s to parse the string, new version 500ms.
Addresses: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23861
Signed-off-by: Karel Zak <kzak@redhat.com>
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>