homed maintains two or three copies of the user's identity record per
home directory: one on the host, one inside the LUKS header, and one
embedded in the home directory.
Previously we'd insist that if a user logs in they have to authenticate
against all three, as a safety feature. This broke logging into
unfixated records however, since in that case the host version is
synthetic and thus does not carry any authentication data.
Let's hence losen the strictness here: accept authentication against
host records that carry no auth data. This should be safe as we know
after all that the second/third record will catch invalid accesses.
Fixes: #15178
The slow-tests= option already enables fuzzers as well, however, this
option can't be used in the "fully sanitized" runs, as certain slow
tests are affected by the performance quite significantly.
This option allows us to enable only fuzzers without the slow tests to
meet the needs of such runs.
Units created with "systemctl edit --full" from generator units aren't
removed with "systemctl revert" because units in the generator,
generator_early, and generator_late paths aren't considered vendor
units.
Alter path_is_vendor() to return true if the given path is a
generator unit, which in turn causes "systemctl revert" to remove units
created with "systemctl edit --full" as they now have vendor versions.
Fixes#10053
ATA devices should use the ATA ids like port number and (possibly)
master/slave or multiplier id, not the generic SCSI ID.
Currently only port number is included in the link. With this patch
the link would be able to support more cases, which are a) when the
device is behind a port multiplexer b) the distinction between master
and slave (distinguished by target id).
I tried to verify scenario a) with this patch, but I failed to find a
machine with PMP SATA devices attached. But the link below
https://github.com/systemd/systemd/issues/3943
could show what's the difference. Here is my test for scenario b)
Current version:
linux-ql21:~ # ll /sys/class/block/sd[ab]
lrwxrwxrwx 1 root root 0 May 8 20:46 /sys/class/block/sda ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:0/3:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 May 8 20:46 /sys/class/block/sdb ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:1/3:0:1:0/block/sdb
linux-ql21:~ # ll /dev/disk/by-path/pci-0000\:00\:01.1-ata-1
lrwxrwxrwx 1 root root 9 May 8 20:44
/dev/disk/by-path/pci-0000:00:01.1-ata-1 -> ../../sdb
linux-ql21:~ # udevadm info /sys/class/block/sda |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1
E: DEVLINKS=/dev/disk/by-id/ata-VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-path/pci-0000:00:01.1-ata-1
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
linux-ql21:~ # udevadm info /sys/class/block/sdb |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1
E: DEVLINKS=/dev/disk/by-id/ata-VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-path/pci-0000:00:01.1-ata-1
After patch applied:
linux-ql21:~ # ll /sys/class/block/sd[ab]
lrwxrwxrwx 1 root root 0 May 8 21:07 /sys/class/block/sda ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:0/3:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 May 8 21:07 /sys/class/block/sdb ->
../../devices/pci0000:00/0000:00:01.1/ata4/host3/target3:0:1/3:0:1:0/block/sdb
linux-ql21:~ # ll /dev/disk/by-path/pci-0000\:00\:01.1-ata-*
lrwxrwxrwx 1 root root 9 May 8 21:07
/dev/disk/by-path/pci-0000:00:01.1-ata-1.0 -> ../../sda
lrwxrwxrwx 1 root root 9 May 8 21:07
/dev/disk/by-path/pci-0000:00:01.1-ata-1.1 -> ../../sdb
linux-ql21:~ # udevadm info /sys/class/block/sda |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1.0
E: DEVLINKS=/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-id/ata-VBOX_HARDDISK_VB3649e885-3e0cdd64
/dev/disk/by-path/pci-0000:00:01.1-ata-1.0
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB3649e885-3e0cdd64
linux-ql21:~ # udevadm info /sys/class/block/sdb |grep by-path
S: disk/by-path/pci-0000:00:01.1-ata-1.1
E: DEVLINKS=/dev/disk/by-id/scsi-0ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/ata-VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-1ATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VBc53b2498-d84ae8de
/dev/disk/by-path/pci-0000:00:01.1-ata-1.1
Changelog:
v5: add another parameter compat_link in handle_scsi()
v4: comment for ID_PATH_ATA_COMPAT
get string length with pointer difference
(suggested by Franck Bui<fbui@suse.com>)
v3: creating compatible link from env
variables type change
v2: remove udev rules modification for compatible link
setup a test scenario of master/slave ATA devices
v1: initial patch
We generally return > 1 if any of the actions we are doing is instantly
complete and == 0 when we started doing it asynchronously (by forking
off homework), in our functions that execute operations on homes.
Fix a mix-up where the test for this was reversed in
home_dispatch_release() and home_dispatch_lock_all().
Fixes: #15684
And do not use it in the IMPORT{cmdline} udev code. Wherever we expose
direct interfaces to check the kernel cmdline, let's not consult our
systemd-specific EFI variable, but strictly use the actual kernel
variable, because that's what we claim we do. i.e. it's fine to use the
EFI variable for our own settings, but for the generic APIs to the
kernel cmdline we should not use it.
Specifically, this applies to IMPORT{cmdline} and
ConditionKernelCommandLine=. In the latter case we weren#t checking the
EFI variable anyway, hence let's do the same for the udev case, too.
Fixes: #15739
In the linked reproducer, m->fields_size == 0, and we calculate ri == -1, which
of course doesn't end well. Skip the whole calculation if m->fields_size == 0,
and also check that we don't go negative even if it is non-zero.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19446 and #15583.
This is a security feature, and we thus shouldn't derive the random MACs
from a potentially guessable source. MAC addresses are after all facing
to the outside, and can be interacted with from untrusted environments.
Hence, let's generate them the same way as we generate UUIDs: from
getrandom() or /dev/urandom, and optionally with RDRAND if that's
supported.
RDRAND should be fine, since this is not cryptographic key material, but
ultimately public information. We just want to make sure conflicts are
not likely.
Previously we'd generate the MACs via rand(), which means given the
short seed they are a little bit too guessable, making collisions too
likely. See #14355 in particular.
Fixes: #14355
(Note that #14355 was already fixed by
a0f11d1d11, but I think we should do
better even, and not rely on rand() and uninitialized random pools)