When exiting, let's explicitly wait for our worker processes to finish
first. That's useful if unmounting of /home/ is scheduled to happen
right after homed is down, as we then can be sure that the home
directories are properly unmounted and detached by the time homed is
fully terminated (otherwise it might happen that our worker gets killed
by the service manager, thus leaving the home directory and its backing
devices up/left for auto-clean which might be async).
Likely fixes#16842
When debugging homed while being logged into a user account manged by
homed it is a good idea to be able to run a second copy of homed. In
order to not collide with its AF_UNIX socket and bus name use, let's add
a new env var $SYSTEMD_HOME_DEBUG_SUFFIX, when set the busnames/socket
names are suffixed by it. When setting this while debugging one can
invoke an additional copy without interfering with the host one.
They are only used under src/home/, but I want to add tests in test-libcrypt-util.c.
And the functions are almost trivial, so I think it is OK to move them to shared.
Remember the secret if the for_state is FIXATING_FOR_ACTIVATION or
FIXATING_FOR_ACQUIRE. This fixes login failures when logging in
to an unfixated user.
"crypt-util.c" is such a generic name, let's avoid that, in particular
as libc's/libcrypt's crypt() function is so generically named too that
one might thing this is about that. Let's hence be more precise, and
make clear that this is about cryptsetup, and nothing else.
We already had cryptsetup-util.[ch] in src/cryptsetup/ doing keyfile
management. To avoid the needless confusion, let's rename that file to
cryptsetup-keyfile.[ch].
This seems to be overridable by setting the SYSTEMD_HOMEWORK_PATH env
variable, but the error message always printed the SYSTEMD_HOMEWORK_PATH
constant.
Let's track the "dirty" state of a home directory backed by a LUKS
volume by setting a new xattr "home.home-dirty" on the backing file
whenever it is in use.
This allows us to later user this information to show a home directory
as "dirty". This is useful because we trim/allocate on log-out, and
if we don't do that a home directory will be larger than necessary. This
fact is something we should communicate to the admin.
The idea is that when an admin sees a user with a "dirty" home directory
they can ask them to log in, to clean up the dirty state, and thus trim
everything again.
For discussion around this see: https://pagure.io/fedora-workstation/issue/82
Recovery keys for homed are very similar to regular passwords, except
that they are exclusively generated by the computer, and not chosen by
the user. The idea is that they are printed or otherwise stored
externally and not what users type in every day.
Taking inspiration from Windows and MacOS this uses 256bit keys. We
format them in 64 yubikey modhex characters, in groups of 8 chars
separated by dashes.
Why yubikey modhex? modhex only uses characters that are are located at
the same place in western keyboard designs. This should reduce the
chance for incorrect inputs for a major chunk of our users, though
certainly not all. This is particular relevant during early boot and
recovery situations, where there's a good chance the keyboard mapping is
not correctly set up.
We return BUS_ERROR_NO_SUCH_UNIT a.k.a. org.freedesktop.systemd1.NoSuchUnit
in various places. In #16813:
Aug 22 06:14:48 core sudo[2769199]: pam_systemd_home(sudo:account): Failed to query user record: Unit dbus-org.freedesktop.home1.service not found.
Aug 22 06:14:48 core dbus-daemon[5311]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Aug 22 06:14:48 core dbus-daemon[5311]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.6564' (uid=0 pid=2769199 comm="sudo su ")
This particular error comes from bus_unit_validate_load_state() in pid1:
case UNIT_NOT_FOUND:
return sd_bus_error_setf(error, BUS_ERROR_NO_SUCH_UNIT, "Unit %s not found.", u->id);
It seems possible that we should return a different error, but it doesn't really
matter: if we change pid1 to return a different error, we still need to handle
BUS_ERROR_NO_SUCH_UNIT as in this patch to handle pid1 with current code.
Apparently both Fedora and suse default to btrfs now, it should hence be
good enough for us too.
This enables a bunch of really nice things for us, most importanly we
can resize home directories freely (i.e. both grow *and* shrink) while
online. It also allows us to add nice subvolume based home directory
snapshotting later on.
Also, whenever we mention the three supported types, alaways mention
them in alphabetical order, which is also our new order of preference.
Also, let's move the glue for this to src/shared/ so that we later can
reuse this in sysemd-firstboot.
Given that libpwquality is a more a leaf dependency, let's make it
runtime optional, so that downstream distros can downgrade their package
deps from Required to Recommended.
The cryptsetup context pins the loop device even after deactivation.
Let's explicitly release the context to make sure the subsequent
loopback device detaching works cleanly.
This how this works on Linux: when atomically creating a file we need to
fully populate it under a temporary name and then when we are fully
done, sync it and the directory it is contained in, before renaming it
to the final name.
../src/home/homectl-pkcs11.c:19:13: warning: ‘pkcs11_callback_data_release’ defined but not used [-Wunused-function]
19 | static void pkcs11_callback_data_release(struct pkcs11_callback_data *data) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is mostly cosmetic, but let's reorder the destructors so that
we do the final sd_notify() call before we run the destructor for
the manager object.
There's some highly specific PKCS#11 code in homectl.c. Let's split that
out, since it is easily isolatable, to make homectl.c a bit more
readable.
No funcional changes, just some moving around and renaming two functions
to make them more suitably named when exported.
When updating a home directory we might update the record first, then
resize the image and finally synchronize the passwords to the storage
layers. These are three individually authenticated operations. Since
each might require touching a FIDO2 or PKCS#11 key we should say what we
are doing. Hence do so.
Usually we are pretty quiet with what we do, and let's stick to that.
Hence show this information only if we actually do more than one thing.
If we only update (and do not resize/sync passwords) then let's be quiet
as usual, as the command line then sufficiently clarifies what we are
doing.
After all, when creating we might need interaction with the security
token too, and our initial attempt to create the user will fail, since
we do not allow interactive auth on the security token, so that we then
can print a log message and retry with interactive auth then enabled.