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.
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Double newlines (i.e. one empty lines) are great to structure code. But
let's avoid triple newlines (i.e. two empty lines), quadruple newlines,
quintuple newlines, …, that's just spurious whitespace.
It's an easy way to drop 121 lines of code, and keeps the coding style
of our sources a bit tigther.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
This macro will read a pointer of any type, return it, and set the
pointer to NULL. This is useful as an explicit concept of passing
ownership of a memory area between pointers.
This takes inspiration from Rust:
https://doc.rust-lang.org/std/option/enum.Option.html#method.take
and was suggested by Alan Jenkins (@sourcejedi).
It drops ~160 lines of code from our codebase, which makes me like it.
Also, I think it clarifies passing of ownership, and thus helps
readability a bit (at least for the initiated who know the new macro)
This removes LOG_TARGET_SAFE. It's made redundant by the new
"prohibit-ipc" logging flag, as it used to have a similar effect: avoid
logging to the journal/syslog, i.e. any local services in order to avoid
deadlocks when we lock from PID 1 or its utility processes (such as
generators).
All previous users of LOG_TARGET_SAFE are switched over to the new
setting. This makes things a bit safer for all, as not even the
SYSTEMD_LOG_TARGET env var can be used to accidentally log to the
journal anymore in these programs.
It's a bit weird to test these strings after the fact instead of before.
Let's make sure that we don't even attempt the string escaping if the
strings are NULL.
Follow-up for #7688
Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Downstream bug: https://bugs.archlinux.org/task/56733
Let's replace usage of fputc_unlocked() and friends by __fsetlocking(f,
FSETLOCKING_BYCALLER). This turns off locking for the entire FILE*,
instead of doing individual per-call decision whether to use normal
calls or _unlocked() calls.
This has various benefits:
1. It's easier to read and easier not to forget
2. It's more comprehensive, as fprintf() and friends are covered too
(as these functions have no _unlocked() counterpart)
3. Philosophically, it's a bit more correct, because it's more a
property of the file handle really whether we ever pass it on to another
thread, not of the operations we then apply to it.
This patch reworks all pieces of codes that so far used fxyz_unlocked()
calls to use __fsetlocking() instead. It also reworks all places that
use open_memstream(), i.e. use stdio FILE* for string manipulations.
Note that this in some way a revert of 4b61c87511.
Let's rename escaped_name to disk_path since this is an actual content
that pointer refers to. It is either path to encrypted block device
or path to encrypted image file.
Also drop redundant function disk_major_minor(). src is always set, and
it always points to either encrypted block device path (or symlink to
such device) or to encrypted image. In case it is set to device path
there is no need to reset it to /dev/block/major:minor symlink since
those paths are equivalent.
Some ask-password agents (e.g. clevis-luks-askpass) use Id option from
/run/systemd/ask-password/ask* file in order to obtain the password for
the device.
Id option should be in the following format,
e.g. Id=subsystem:data. Where data part is supposed to identify object
that ask-password query is done for. Since
e51b9486d1 this field has format
Id=cryptsetup:/dev/block/major:minor when systemd-cryptsetup is
unlocking encrypted block device. However, crypttab also supports
encrypted image files in which case we usually set data part of Id to
"vol on mountpoint". This is unexpected and actually breaks network
based device encryption as implemented by clevis.
Example:
$ cat /etc/crypttab
clevis-unlocked /clevis-test-disk-image none luks,_netdev
$ systemctl start 'systemd-cryptsetup@clevis\x2dunlocked.service'
$ grep Id /run/systemd/ask-password/ask*
Before:
$ Id=cryptsetup:clevis-unlocked on /clevis-test-disk-image-mnt
After:
$ Id=cryptsetup:/clevis-test-disk-image
Also do not include libcryptsetup.h directly, but only through crypt-util.h.
This way we do not have to repeat the define in every file where it is used.
Let's always escape strings we receive from the user before writing them
out to unit file settings that suppor specifier expansion, so that user
strings are transported as-is.
remote-cryptsetup-pre.target was designed as an active unit (that pulls in
network-online.target), the opposite of remote-fs-pre.target (a passive unit,
with individual provider services ordering itself before it and pulling it in,
for example iscsi.service and nfs-client.target).
To make remote-cryptsetup-pre.target really work, those services should be
ordered before it too. But this would require updates to all those services,
not just changes from systemd side.
But the requirements for remote-fs-pre.target and remote-cryptset-pre.target
are fairly similar (e.g. iscsi devices can certainly be used for both), so
let's reuse remote-fs-pre.target also for remote cryptsetup units. This loses
a bit of flexibility, but does away with the requirement for various provider
services to know about remote-cryptsetup-pre.target.
Allow cryptsetup utility to activate LUKS2 devices (with appropriate
libcryptsetup)
The change itself doesn't enforce new libcryptsetup 2.x and is backward
compatible with versions 1.x
We want that cryptsetup can cache keys between multiple invocations, and
it does so via the root user's user keyring, hence let's share it among
services.
Replaces: #6286
When building without veracrypt, gcc warns
../src/cryptsetup/cryptsetup.c:55:13: warning: ‘arg_tcrypt_veracrypt’ defined but not used [-Wunused-variable]
static bool arg_tcrypt_veracrypt = false;
Fix this by conditionalizing the declaration.
This breaks things when the decrypted device is not immediately
`SYSTEMD_READY=1` (e. g. when a multi-device btrfs system is placed on
multiple cryptsetup devices).
Fixes#6537.
As a follow-up for db3f45e2d2 let's do the
same for all other cases where we create a FILE* with local scope and
know that no other threads hence can have access to it.
For most cases this shouldn't change much really, but this should speed
dbus introspection and calender time formatting up a bit.
It seems that there's a common pattern among the various generators. Let's add
a helper function for it and make use of it in cryptsetup-generator.
This fixes a bunch of theoretical memleaks in error paths, since *to wasn't
generally freed properly. Not thath it matters.
This extends 2d79a0bbb9 to the kernel
command line parsing.
The parsing is changed a bit to only understand "0" as infinity. If units are
specified, parse normally, e.g. "0s" is just 0. This makes it possible to
provide a zero timeout if necessary.
Simple test is added.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1462378.
If the cryptsetup service unit and swap unit for a swap device
are not strictly ordered, it might happen that the swap unit
activates/mounts the swap device before its cryptsetup service unit
has a chance to run the 'mkswap' command (that it is programmed to).
This leads to the following error:
Starting Cryptography Setup for sda3_crypt...
[ OK ] Found device /dev/mapper/sda3_crypt.
Activating swap /dev/mapper/sda3_crypt...
[ OK ] Activated swap /dev/mapper/sda3_crypt.
[ OK ] Reached target Swap.
[FAILED] Failed to start Cryptography Setup for sda3_crypt.
See 'systemctl status systemd-cryptsetup@sda3_crypt.service' for
details.
[DEPEND] Dependency failed for Encrypted Volumes.
Which happens because the swap device is already mounted:
# systemctl status systemd-cryptsetup@sda3_crypt.service
<...>
Active: failed (Result: exit-code) since Mon 2017-02-27 14:21:43 CST;
54s ago
<...>
<...> systemd[1]: Starting Cryptography Setup for sda3_crypt...
<...> mkswap[2420]: mkswap: error: /dev/mapper/sda3_crypt is mounted;
will not make swapspace
<...>
So, modify cryptsetup-generator to include a 'Before=' option for the
respective 'dev-mapper-%i.swap' device in the cryptsetup service unit.
Now, correct ordering is ensured, and the error no longer occurs:
Starting Cryptography Setup for sda3_crypt...
[ OK ] Found device /dev/mapper/sda3_crypt.
[ OK ] Started Cryptography Setup for sda3_crypt.
Activating swap /dev/mapper/sda3_crypt...
[ OK ] Reached target Encrypted Volumes.
[ OK ] Activated swap /dev/mapper/sda3_crypt.
[ OK ] Reached target Swap.
This improves kernel command line parsing in a number of ways:
a) An kernel option "foo_bar=xyz" is now considered equivalent to
"foo-bar-xyz", i.e. when comparing kernel command line option names "-" and
"_" are now considered equivalent (this only applies to the option names
though, not the option values!). Most of our kernel options used "-" as word
separator in kernel command line options so far, but some used "_". With
this change, which was a source of confusion for users (well, at least of
one user: myself, I just couldn't remember that it's systemd.debug-shell,
not systemd.debug_shell). Considering both as equivalent is inspired how
modern kernel module loading normalizes all kernel module names to use
underscores now too.
b) All options previously using a dash for separating words in kernel command
line options now use an underscore instead, in all documentation and in
code. Since a) has been implemented this should not create any compatibility
problems, but normalizes our documentation and our code.
c) All kernel command line options which take booleans (or are boolean-like)
have been reworked so that "foobar" (without argument) is now equivalent to
"foobar=1" (but not "foobar=0"), thus normalizing the handling of our
boolean arguments. Specifically this means systemd.debug-shell and
systemd_debug_shell=1 are now entirely equivalent.
d) All kernel command line options which take an argument, and where no
argument is specified will now result in a log message. e.g. passing just
"systemd.unit" will no result in a complain that it needs an argument. This
is implemented in the proc_cmdline_missing_value() function.
e) There's now a call proc_cmdline_get_bool() similar to proc_cmdline_get_key()
that parses booleans (following the logic explained in c).
f) The proc_cmdline_parse() call's boolean argument has been replaced by a new
flags argument that takes a common set of bits with proc_cmdline_get_key().
g) All kernel command line APIs now begin with the same "proc_cmdline_" prefix.
h) There are now tests for much of this. Yay!
I think it's an antipattern to have to count the number of bytes in
the prefix by hand. We should do this automatically to avoid wasting
programmer time, and possible errors. I didn't any offsets that were
wrong, so this change is mostly to make future development easier.
This stripping is contolled by a new boolean parameter. When the parameter
is true, it means that the caller does not care about the distinction between
initrd and real root, and wants to act on both rd-dot-prefixed and unprefixed
parameters in the initramfs, and only on the unprefixed parameters in real
root. If the parameter is false, behaviour is the same as before.
Changes by caller:
log.c (systemd.log_*): changed to accept rd-dot-prefix params
pid1: no change, custom logic
cryptsetup-generator: no change, still accepts rd-dot-prefix params
debug-generator: no change, does not accept rd-dot-prefix params
fsck: changed to accept rd-dot-prefix params
fstab-generator: no change, custom logic
gpt-auto-generator: no change, custom logic
hibernate-resume-generator: no change, does not accept rd-dot-prefix params
journald: changed to accept rd-dot-prefix params
modules-load: no change, still accepts rd-dot-prefix params
quote-check: no change, does not accept rd-dot-prefix params
udevd: no change, still accepts rd-dot-prefix params
I added support for "rd." params in the three cases where I think it's
useful: logging, fsck options, journald forwarding options.
It could be that our .service is being stopped precisely because the
device already disappeared (e.g. due to a manual `cryptsetup close`, or
due to UDisks2 cleaning up).
GLIB has recently started to officially support the gcc cleanup
attribute in its public API, hence let's do the same for our APIs.
With this patch we'll define an xyz_unrefp() call for each public
xyz_unref() call, to make it easy to use inside a
__attribute__((cleanup())) expression. Then, all code is ported over to
make use of this.
The new calls are also documented in the man pages, with examples how to
use them (well, I only added docs where the _unref() call itself already
had docs, and the examples, only cover sd_bus_unrefp() and
sd_event_unrefp()).
This also renames sd_lldp_free() to sd_lldp_unref(), since that's how we
tend to call our destructors these days.
Note that this defines no public macro that wraps gcc's attribute and
makes it easier to use. While I think it's our duty in the library to
make our stuff easy to use, I figure it's not our duty to make gcc's own
features easy to use on its own. Most likely, client code which wants to
make use of this should define its own:
#define _cleanup_(function) __attribute__((cleanup(function)))
Or similar, to make the gcc feature easier to use.
Making this logic public has the benefit that we can remove three header
files whose only purpose was to define these functions internally.
See #2008.
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
This adds support for caching harddisk passwords in the kernel keyring
if it is available, thus supporting caching without Plymouth being
around.
This is also useful for hooking up "gdm-auto-login" with the collected
boot-time harddisk password, in order to support gnome keyring
passphrase unlocking via the HDD password, if it is the same.
Any passwords added to the kernel keyring this way have a timeout of
2.5min at which time they are purged from the kernel.
If cryptsetup is called with a source device as argv[3], then craft the
ID for the password agent with a unique device path.
If possible "/dev/block/<maj>:<min>" is used, otherwise the original
argv[3] is used.
This enables password agents like petera [1] to provide a password
according to the source device. The original ID did not carry enough
information and was more targeted for a human readable string, which
is specified in the "Message" field anyway.
With this patch the ID of the ask.XXX ini file looks like this:
ID=cryptsetup:/dev/block/<maj>:<min>
[1] https://github.com/npmccallum/petera
A variety of changes:
- Make sure all our calls distuingish OOM from other errors if OOM is
not the only error possible.
- Be much stricter when parsing escaped paths, do not accept trailing or
leading escaped slashes.
- Change unit validation to take a bit mask for allowing plain names,
instance names or template names or an combination thereof.
- Refuse manipulating invalid unit name
This file contains no privileged data — just names of devices to decrypt
and files containing keys. On a running system most of this can be inferred from
the device tree anyway.
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
After all it is now much more like strjoin() than strappend(). At the
same time, add support for NULL sentinels, even if they are normally not
necessary.
We would ignore options like "fail" and "auto", and for any option
which takes a value the first assignment would win. Repeated and
options equivalent to the default are rarely used, but they have been
documented forever, and people might use them. Especially on the
kernel command line it is easier to append a repeated or negated
option at the end.
If the format string contains %m, clearly errno must have a meaningful
value, so we might as well use log_*_errno to have ERRNO= logged.
Using:
find . -name '*.[ch]' | xargs sed -r -i -e \
's/log_(debug|info|notice|warning|error|emergency)\((".*%m.*")/log_\1_errno(errno, \2/'
Plus some whitespace, linewrap, and indent adjustments.
As a followup to 086891e5c1 "log: add an "error" parameter to all
low-level logging calls and intrdouce log_error_errno() as log calls
that take error numbers", use sed to convert the simple cases to use
the new macros:
find . -name '*.[ch]' | xargs sed -r -i -e \
's/log_(debug|info|notice|warning|error|emergency)\("(.*)%s"(.*), strerror\(-([a-zA-Z_]+)\)\);/log_\1_errno(-\4, "\2%m"\3);/'
Multi-line log_*() invocations are not covered.
And we also should add log_unit_*_errno().
For plain dm-crypt devices, the behavior of cryptsetup package is to
ignore the hash algorithm when a key file is provided. It seems wrong
to ignore a hash when it is explicitly specified, but we should default
to no hash if the keyfile is specified.
https://bugs.freedesktop.org/show_bug.cgi?id=52630
Fix a bug in systemd-cryptsetup-generator which caused the drop-in
setting the job timeout for the dm device unit to be written with a
name different than the unit name.
https://bugs.freedesktop.org/show_bug.cgi?id=84409
String which ended in an unfinished quote were accepted, potentially
with bad memory accesses.
Reject anything which ends in a unfished quote, or contains
non-whitespace characters right after the closing quote.
_FOREACH_WORD now returns the invalid character in *state. But this return
value is not checked anywhere yet.
Also, make 'word' and 'state' variables const pointers, and rename 'w'
to 'word' in various places. Things are easier to read if the same name
is used consistently.
mbiebl_> am I correct that something like this doesn't work
mbiebl_> ExecStart=/usr/bin/encfs --extpass='/bin/systemd-ask-passwd "Unlock EncFS"'
mbiebl_> systemd seems to strip of the quotes
mbiebl_> systemctl status shows
mbiebl_> ExecStart=/usr/bin/encfs --extpass='/bin/systemd-ask-password Unlock EncFS $RootDir $MountPoint
mbiebl_> which is pretty weird
There is a small number of the places in sources where we don't check
asprintf() return code and assume that after error the function
returns NULL pointer via the first argument. That's wrong, after
error the content of pointer is undefined.
As special magic, don't create device dependencies for /dev/null. Of
course, there might be similar devices we might want to include, but
given that none of them really make sense to specify as password source
there's really no point in checking for anything else here.
https://bugs.freedesktop.org/show_bug.cgi?id=75816
The command line key-size is in bits but the libcryptsetup API expects bytes.
Note that the modulo 8 check is in the original cryptsetup binary as well, so
it's no new limitation.
(v2: changed the point at which the /= 8 is performed, rebased, removed tabs)
Add an (optional) "Id" key in the password agent .ask files. The Id is
supposed to be a simple string in "<subsystem>:<target>" form which
is used to provide more information on what the requested passphrase
is to be used for (which e.g. allows an agent to only react to cryptsetup
requests).
(v2: rebased, fixed indentation, escape name, use strappenda)
In cryptsetup-generator automatic cleanup had to be replaced
with manual cleanup, and the code gets a bit longer. But existing
code had the issue that it returned negative values from main(),
which was wrong, so should be reworked anyway.
Debian recently introduced the option key-slot to /etc/crypttab to
specify the LUKS key slot to be used for decrypting the device. On
systems where a keyfile is used and the key is not in the first slot,
this can speed up the boot process quite a bit, since cryptsetup does
not need to try all of the slots sequentially. (Unsuccessfully testing
a key slot typically takes up to about 1 second.)
This patch makes systemd aware of this option.
Debian bug that introduced the feature:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704470
Instead of individually checking for containers in each user do this
once in a new call proc_cmdline() that read the file only if we are not
in a container.
When crypttab contains noauto, cryptsetup service does not have any
explicit dependencies. If service is started later manually (directly or via
mount dependency) it will be stopped on isolate.
mount units already have IgnoreOnIsolate set by default. Set it by
default for cryptsetup units as well.
The main usecase for this is to make it possible to use cryptsetup in
the initrd without it having to include a host-specific /etc/crypttab.
Tested-by: Thomas Bächler <thomas@archlinux.org>
systemd-cryptsetup recognizes option 'allow-discards' in /etc/crypttab
to enable TRIM passthrough to underlying encrypted device. In Debian
this option was changed to 'discard' to avoid hyphen in option name.
(see: #648868 and `man crypttab`).
[zj: update crypttab(5) too, making "discard" the default.]
Tcrypt uses a different approach to passphrases/key files. The
passphrase and all key files are incorporated into the "password"
to open the volume. So, the idea of slots that provide a way to
open the volume with different passphrases/key files that are
independent from each other like with LUKS does not apply.
Therefore, we use the key file from /etc/crypttab as the source
for the passphrase. The actual key files that are combined with
the passphrase into a password are provided as a new option in
/etc/crypttab and can be given multiple times if more than one
key file is used by a volume.
