The subvolumes set is a set of source inodes similar to how the
denylist hashmap contains source inodes as keys. It indicates
directories in the source tree that should become subvolumes in
the target tree.
We use usec_t for storing time value, which is 64bit.
However, usleep() takes useconds_t that is (typically?) 32bit.
Also, usleep() may only support the range [0, 1000000].
This introduce usleep_safe() which takes usec_t.
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
This adds uidmap shifting also when resizing/updating/changing
passwords. Prviously I thought we didn't have to, because the user is
not going to access the uidmap if we only quickly activate the home
area. But this thinking is wrong, because the three operations will
result in an update ~/.identity fie to be written, and we should do that
with uidmap applied, so that its ownership maps down to nobody below as
intended.
Fixes: #21441
When we want to operate on an already activated home area we so far
tried to reapply the uidmapping logic. We shouldn't do that, it's
already applied after all.
We only want to apply this for newly activated home areas. Hence check
for the right HomeSetupFlags flag for it HOME_SETUP_ALREADY_ACTIVATED.
The patch is actually in theory a two-liner. Except that so far we don#t
pass the HomeSetupFlags flags down all necessary functions where the
uidmap stuff will eventually run. Hence this larger than intended
commit.
If we do automatic disk space rebalancing, we must be able to unlock the
encrypted volume for that in the background, thus we need to decryption
key around in userspace. Let's do this via the kernel keyring. This
allows us to do this in a relatively secure way, so that it sticks
around between homework invocations, but still is destroyed
automatically when homed goes down.
Let's first move the home dir to a new mount point that is only visible
in our own private namespace. Then, do FITRIM and stuff there, so that
we know the regular userspace can't interfere with that, and we know
that the home fs is not used anymore.
(This will become even more important once we add auto-grow/auto-shrink
for home dirs)
This teachs the LUKS backend UID mapping, similar to the existing
logic for the "directory", "subvolume" and "fscrypt" backends: the files
will be owned by "nobody" on the fs itself, but will be mapped to
logging in user via uidmapped mounts.
This way LUKS home dirs become truly portable: no local UID info will
leak onto the images anymore, and the need to recursively chown them on
activation goes away. This means activation is always as performant as
it should be.
Let's simplify things further a bit and move the destruction of the
temporary image file we operate on when creating a LUKS home into
HomeSetup, like all our other resources.
We actually already detach/free the LUKS DM devices for most operations
via HomeSetup, let's move the creation logic to also do this, in order
to unify behaviour between operations.
This is just some minor refactoring, to make these two operations work
like the rest.
home_lock_luks() will now use the root_fd field of HomeSetup already,
but for home_unlock_luks() + home_deactivate() this change has no effect for now. (But a
later commit will change this.)
Allow specifying CIFS services in the format //host/service/subdir/… to
allow multiple homedirs on the same share, and not in the main dir of
the share.
All other backends allow placing the data store at arbitrary places,
let's allow this too for the CIFS backend. This is particularly useful
for testing.
Similar to the same chage we did for the directory backend. Let's always
path the setup context object, i.e. HomeSetup, and store whatever we set
up in there.
No actual change in behaviour.
Let's migrate home_create_directory_or_subvolume() to also use HomeSetup
for storing its runtime objects we'd like to destroy in case of failure.
In the beginning this is just the root_fd, but later on we can add more.
No change in behaviour, just shifting things around.
We use this work dir a various places, and it's easy to mistype, hence
let the compiler detect this for us, and introduce a macro for it.
No code changes, just some search/replace.
Previously in most cases we'd allocate the HomeSetup context object
in generic code in homework.c. But for some cases we allocated them
instead inside the specific code in homework-{cifs,directory,luks}.c
Let's clean that up, and systematically allocate it in the outer
"entrypoint" calls in homework.c instead of the inner ones.
This doesn't change much in behaviour (i.e. it just means when something
fails we'll now clean it up one stack frame further up). But it will
allow is to more easily work with the context objects, since we'll have
them around in all stack frames.
This function is a destructor, hence it should be named like one.
(We usually use xyz_free() for a destructor that frees the object passed
itself. xyz_unref() we typically use for destructors that are similar,
but ref counted. xyz_done() usually is used for destructors which free
the members of an object, but not the object itself – to allow stack
allocation of objects. We don't strictly follow this, but it's good to
stick to rules wherever we can.)
No actual code change, just renaming.
These set of functions are constructors for an object called HomeSetup,
which has a destructor home_setup_undo(), hence to be reasonably
symmetric, let's call it home_setup*() too, instead of using a new verb
"prepare" for its name.
No actual code changes, just some renaming.
We have the same code at two places, let's reuse it. Given the more
generic scope let's rename the function home_get_state() since it
retrieve the current setup state of the LUKS logic.
This is a debugging feature. It's sometimes incredibly useful to be able
to run a second instance of homed that operates on another dir than
/home/.
Specifically, if you build homed from the source tree you can now run an
instance of it pretty reasonably directly from the build tree via:
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo SYSTEMD_HOMEWORK_PATH=$(pwd)/build/systemd-homework SYSTEMD_HOME_ROOT=/home/foo ./build/systemd-homed
And then talk to it via
sudo SYSTEMD_HOME_DEBUG_SUFFIX=foo homectl …
(you might need to tweak your dbus policy for this to work fully though)
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
The goal is to move everything that requires selinux or smack
away from src/basic/. This means that src/basic/label.[ch] must move,
which implies btrfs-util.[ch], copy.[ch], and a bunch of other files
which form a cluster of internal use.
This is just moving text around, so there should be no functional difference.
test-blockdev-util is new, because path_is_encrypted() is moved to
blockdev-util.c, and so far we didn't have any tests for code there.
We want user records to be extensible, hence we shouldn't complain about
fields we can't parse. In particular we want them to be extensible for
our own future extensions.
Some code already turned the permissive flag when parsing the JSON data,
but most did not. Fix that. A few select cases remain where the bit is
not set: where we just gnerated the JSON data ourselves, and thus can be
reasonably sure that if we can't parse it it's our immediate programming
error and not just us processing a user record from some other tool or a
newer version of ourselves.
This catches up homed's FIDO2 support with cryptsetup's: we'll now store
the uv/up/clientPin configuration at enrollment in the user record JSON
data, and use it when authenticating with it.
This also adds explicit "uv" support: we'll only allow it to happen when
the client explicity said it's OK. This is then used by clients to print
a nice message suggesting "uv" has to take place before retrying
allowing it this time. This is modelled after the existing handling for
"up".
Daan De Meyer
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
nl6720
Lennart Poettering