cryptsetup: handle parallel activation of volumes with another tool gracefully

[kszczek]

This commit makes systemd-cryptsetup exit with a successful status when the volume gets unlocked outside of the current systemd-cryptsetup process while it was executing. This can be easily reproduced by calling systemd-cryptsetup, and while it waits for user to input a password/PIN, unlock the volume in a second terminal. Then after entering the password systemd-cryptsetup will exit with a non-zero status code.

[github-actions]

Important

An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released.

[poettering]

hmm, this is a really weird usecase. I am not really sure we should hide this kind of error, it seems really really specific to me, in particular as it's not clear if the activated volume really matches our expecations if we see EEXIST. could very well be some other device, no?

[kszczek]

The situation I described is somewhat simplified, just an easy way to reproduce the issue. My actual use-case is a little bit more complex. I have a socket unit, which when triggered, assembles the key via a combination of TPM2 + FIDO2 devices. But the problem is, when TPM2 unseal fails or some other issue happens, I want to be able to use another "recovery" token. The problem is that systemd-cryptsetup falls back to a password prompt if the key acquired from the socket doesn't check out, so I can't use the recovery token on the second attempt, only passwords. I worked around this issue by calling another instance of systemd-cryptsetup in my aformentioned "keyscript", but this causes the issue described to arise. But the issue is mostly cosmetical, the system continues to boot, but the systemd-cryptsetup@ units show up as failed, even though the volumes are unlocked.

But yes, I agree with you that we can't guarantee that the device that was unlocked by the other tool is the same we are trying to unlock. But then maybe we could exit with a dedicated status code which would inform the caller of systemd-cryptsetup that the volume was already unlocked? This would allow me to solve the problem in my use-case by writing a drop-in unit for systemd-cryptsetup@ to treat this status code as success.

Also, currently systemd-cryptsetup exits with status code 1 in the situation described above, but also exits with status code 0 on subsequent invocations, doesn't this behavior also break expectations?

systemd/src/cryptsetup/cryptsetup.c

Lines 2345 to 2349 in ce2aade

	status = crypt_status(cd, volume);
	if (IN_SET(status, CRYPT_ACTIVE, CRYPT_BUSY)) {
	log_info("Volume %s already active.", volume);
	return 0;
	}

🔐 Please enter passphrase for disk Linux LUKS (test): ••••••••                
Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/vda3.
Device test already exists.
Failed to activate with specified passphrase: File exists
test@legion:~$ echo $?
1
test@legion:~$ sudo systemd-cryptsetup attach test /dev/vda3
Volume test already active.
test@legion:~$ echo $?
0
test@legion:~$ 

[kszczek]

Okay, I've just learned that systemd-cryptsetup will always exit with EXIT_FAILURE no matter what the underlying error is, but it will send a notification using sd_notify with the actual errno, guess I didn't RTFM 😄

You have to add a drop-in for the systemd-cryptsetup@ unit though, because it uses Type=oneshot which will ignore these notifications by default. The drop-in unit has to set NotifyAccess=main in the [Service] section.

But the inconsistency I've mentioned in the comment above still stands. There are race conditions which will sometimes make systemd-cryptsetup exit with status code 1 and errno 17 (File exists), and in some other cases it will exit with status code 0 (the code snippet mentioned above). Are we concerned about this inconsistency?

Also off-topic: I'm struggling to find a way to make systemd treat errno 17 (File exists) as a successful exit of systemd-cryptsetup. I've tried SuccessExitStatus=, but it seems to apply only to the actual exit status code and not the errno. Have I missed anything in the docs which might help me here?