| Commit message (Collapse) | Author | Files | Lines |
|
This will help in a later commit to separate userspace from EFI builds.
|
|
Function didn't actually return anything useful. Quite a shame.
|
|
|
|
This enables the ManagerEnvironment= settings in the user's user.conf to
reference some user data like $HOME for the purpose of setting
environment variables derived from these values.
|
|
|
|
Follow-up for: b25a930f0e2ebe77bc8b0f0acfac8a3b27ef1f0a
|
|
This changes the PSI window duration we default to for watching memory
pressure events from 1s to 2s. This is because apparently the kernel
will soon disallow window durations other than 2s for unprivileged
processes.
Hence, we'll bump the threshold from 100m to 200ms, and the window from
1s to 2s.
|
|
|
|
symlinks
Let's test that everything we just added works in combination.
|
|
mount_option_supported()
|
|
|
|
And let's also ask the kernel explicitly for support.
|
|
support for an fs
|
|
|
|
This way we'll have the same mount options in place if we boot via the
gpt generator, or if we mount a DDI locally.
Note that this will also enable MS_NOSYMFOLLOW on ESP and XBOOTLDR now,
if booted via gpt-auto-generator.
|
|
When we mount a DDI, let's set MS_NOSYMFOLLOW for ESP/XBOOTLDR. They are
generally untrusted territory, (i.e. outside of
encryption/authentication via dm-crypt/dm-verity). Moreover they are
generally FAT, where symlinks don't exist anyway. Let's hence disable
symlinks for them.
This slightly refactors how we put together mount options for mounts,
splitting this out into a new helper call
dissected_partition_pick_options(), which we should be able to reuse
later in gpt-auto-generator, to ensure mounts via loopback as DDI and
those on bare metal get the same options.
|
|
|
|
|
|
This renames some functions to match other to/from_string() naming,
and allows better management of TPML_PCR_SELECTION and TPMS_PCR_SELECTION
structs.
|
|
|
|
|
|
|
|
This adds symlinks that allow accessing loopback block devices via stable
names that reference their backing block devices, make the unpredictable
naming of loopback devices less of an issue.
Example:
1. Create a loopback block device for a file $F
losetup --find $F
2. Reference the backing block device via its inode:
L="$(stat -c '/dev/loop/by-inode/%Hd:%Ld-%i' $F)"
fdisk $L
In the above the loop device name (which might be /dev/loop47 or any
other name) is not used at all.
|
|
|
|
When attaching a loopback file this allows us to set an explicit name
for it. This is useful since it allows a caller to pre-select a string
that is directly attached to the loopback file. Via udev rules we'l
later make the device accessible through this name.
Note that "lo_file_name" is supposed to carry a file name of the backing
file, but the kernel actually does not care or enforce any of that, it
just stores the filename and returns it later. This makes it so useful,
as userspace has total control of that field.
"lo_file_name" should not be confused with the sysattr
"loop/backing_file" which is actually maintained by the kernel itself,
and always shows the file to the backing inode without userspace having
direct control over the returned string. Because the sysattr is
generated by the kernel it is subject to file system namespacing and
everything, while "lo_file_name" is not, it's really just a string
passed through the kernel.
|
|
Sometimes it is useful attaching DDIs without mounting them. We could
use "losetup" for that, but doing this in systemd-dissect has various
benefits:
1. we superficially validate the DDI first
2. we set the sector size depending on what we determine
3. we synchronously create the per-partition block devices
|
|
|
|
|
|
|
|
This adds support for retrieving info about the inode backing a loopback
file to udev-builtin-blkid. It will pick up the inode number and device
of the backing inode, as well as the lo_file_name[] array that the
loopback device maintains.
A later patch uses this information to create block device symlinks in
/dev/ that allow refering block devices by their backing inodes. This is
useful when separate tools set up a loopback device from those which
ultimately shall mount them, and there shall be a stable reference be
passed along. For example, we can add a new kernel option setuploop= or
so which allows setting up a block device via a generator, and still
have a way to safely reference later.
And yes, this doesn't directly have anything to do with the probing
libblkid does, but it's close enough, and we have the device open anyway
here, so the additional ioctl() here should not hurt.
|
|
|
|
Initially we only have one user, but following patches will add more.
|
|
|
|
|
|
|