This reverts a part of commit 49fe5c0996 ('tree-wide: port various places
over to STARTSWITH_SET()') that replaced a pair of startswith() calls
with STARTSWITH_SET().
They were in fact for a different strings (device vs. name), botching
the crypttap parsing.
prefix_root() is equivalent to path_join() in almost all ways, hence
let's remove it.
There are subtle differences though: prefix_root() will try shorten
multiple "/" before and after the prefix. path_join() doesn't do that.
This means prefix_root() might return a string shorter than both its
inputs combined, while path_join() never does that. I like the
path_join() semantics better, hence I think dropping prefix_root() is
totally OK. In the end the strings generated by both functon should
always be identical in terms of path_equal() if not streq().
This leaves prefix_roota() in place. Ideally we'd have path_joina(), but
I don't think we can reasonably implement that as a macro. or maybe we
can? (if so, sounds like something for a later PR)
Also add in a few missing OOM checks
Fixes#12650
cryptsetup: Extract dependency check to a separate function
cryptsetup: style improvements, error checking
Return early on failure/nothing to do
Removed braces from single-line ifs
Check return value of fstab_filter_options
cryptsetup: code style
LUKS2 supports so-called tokens. The libcryptsetup internally
support keyring token (it tries to open device using specified
keyring entry).
Only if all token fails (or are not available), it uses a passphrase.
This patch aligns the functionality with the cryptsetup utility
(cryptsetup luksOpen tries tokens first) but does not replace
the systemd native ask-password function (can be used the same in
combination with this patch).
The crypt_load() for LUKS2 can read a quite big area of disk
(metadata area size is configurable and can increase up to megabytes).
This initialization is not needed to be repeated, just use the existing context.
(This patch is also required for the following change.)
If crypt_load() for LUKS succeeds, we know that it is a LUKS device.
Failure of data device setting should fail in this case; remapping
as a PLAIN device late could mean data corruption.
(If a user wants to map PLAIN device over a device with LUKS header,
it should be said explicitly with "plain" argument type.)
Also, if there is no explicit PLAIN type requested and crypt device
is already initialized (crypt_data_type() is set), do not run
the initialization again.
With new LUKS2 header format it is possible to use Argon2 key derivation
function. This function is "memory-hard" hence keyslot unlocking can
potentially use a lot of RAM as this increases resistance to massively
parallel GPU based password cracking.
However, when multiple systemd-cryptsetup binaries run at the same
time it is very likely that system using Argon2 (e.g. Fedora 30)
will encounter memory-pressure during early boot, following OOM killing
spree.
This patch aims to lower the damage done by OOM killer and sets OOMScore
for systemd-cryptsetup units to 500. Hopefully OOM killer will then
shoot us down and leave rest of the system services alone.
6f177c7dc0 caused key file errors to immediately fail, which would make it hard to correct an issue due to e.g. a crypttab typo or a damaged key file.
Closes#11723.
As device units will be reloaded by systemd whenever the corresponding device generates a "changed" event, if the mount unit / cryptsetup service is wanted by its device unit, the former can be restarted by systemd unexpectedly after the user stopped them explicitly. It is not sensible at all and can be considered dangerous. Neither is the behaviour conventional (as `auto` in fstab should only affect behaviour on boot and `mount -a`) or ever documented at all (not even in systemd, see systemd.mount(5) and crypttab(5)).
First of all let's always log where the errors happen, and not in an
upper stackframe, in all cases. Previously we'd do this somethis one way
and sometimes another, which resulted in sometimes duplicate logging and
sometimes none.
When we cannot activate something due to bad password the kernel gives
us EPERM. Let's uniformly return this EAGAIN, so tha the next password
is tried. (previously this was done in most cases but not in all)
When we get EPERM let's also explicitly indicate that this probably
means the password is simply wrong.
Fixes: #11498
There should be no functional difference, except that the error message
is changd from "three or no arguments" to "zero or three arguments". Somehow
the inverted form always seemed strange.
umask() call is also dropped from run-generator. I think it wasn't dropped in
053254e3cb because the run generator was merged
around the same time.
Ideally, coccinelle would strip unnecessary braces too. But I do not see any
option in coccinelle for this, so instead, I edited the patch text using
search&replace to remove the braces. Unfortunately this is not fully automatic,
in particular it didn't deal well with if-else-if-else blocks and ifdefs, so
there is an increased likelikehood be some bugs in such spots.
I also removed part of the patch that coccinelle generated for udev, where we
returns -1 for failure. This should be fixed independently.
systemd already sets the umask (see e3b8d0637d). When
running under systemd, we don't need to set it. And when *not* running under
systemd, for example during development, there is no reason to override the user
config. Let's just drop those calls.
$ git grep -e 'umask\(' -l 'src/*generator*' |xargs perl -i -0pe 's|^[^\n]*umask\([^\n]+\n\n||gms'
All users of the macro (except for one, in serialize.c), use the macro in
connection with read_line(), so they must include fileio.h. Let's not play
libc games and require multiple header file to be included for the most common
use of a function.
The removal of def.h includes is not exact. I mostly went over the commits that
switch over to use read_line() and add def.h at the same time and reverted the
addition of def.h in those files.
For example, <luks.uuid>=/keyfile:LABEL="KEYFILE FS" previously wouldn't
work, because we truncated label at the first whitespace character,
i.e. LABEL="KEYFILE".
Instead of
Please enter passphrase for disk <disk-name>!
use
Please enter passphrase for disk <disk-name>:
which is more polite and matches Plymouth convention.
We are not the ones receiving an error here, but the ones generating it,
hence we shouldn't show it with %m, that's just confusing, as it
suggests we received an error from some other call.
Dracut has a support for unlocking encrypted drives with keyfile stored
on the external drive. This support is included in the generated initrd
only if systemd module is not included.
When systemd is used in initrd then attachment of encrypted drives is
handled by systemd-cryptsetup tools. Our generator has support for
keyfile, however, it didn't support keyfile on the external block
device (keydev).
This commit introduces basic keydev support. Keydev can be specified per
luks.uuid on the kernel command line. Keydev is automatically mounted
during boot and we look for keyfile in the keydev
mountpoint (i.e. keyfile path is prefixed with the keydev mount point
path). After crypt device is attached we automatically unmount
where keyfile resides.
Example:
rd.luks.key=70bc876b-f627-4038-9049-3080d79d2165=/key:LABEL=KEYDEV
This is a bit like the info link in most of GNU's --help texts, but we
don't do info but man pages, and we make them properly clickable on
terminal supporting that, because awesome.
I think it's generally advisable to link up our (brief) --help texts and
our (more comprehensive) man pages a bit, so this should be an easy and
straight-forward way to do it.
