[systemd-devel] cryptsetup units are actuvated by default

[Andrey Borzenkov]

On Mon, Feb 14, 2011 at 12:50 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sat, 12.02.11 09:11, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
>
>> Currently all encrypted disks found in crtypttab are activated (by
>> adding WantedBy cryptsetup.target) unless cryptsetup contains noauto.
>>
>> Unfortunately noauto is not even documented in cryptsetup man page and
>> is unlikely to be present on any system. The standard behaviour, found
>> at least in RH-like init scripts is to activate those encypted
>> containers that are needed for file systems mounted on boot
>> (respectively, for those that are swap).
>
> The "noauto" option originates from Debian. It appeared quite useful to
> me which is why I added it to the generic systemd implementation of the
> crypto stuff.
>
> Hmm, they way I read
> http://git.fedorahosted.org/git/?p=initscripts.git;a=blob;f=rc.d/init.d/functions;h=1256d10e452816a4a60dbfddfd31cb8b292886c8;hb=HEAD
> we actually activate all crypto devices, there is no matching up against
> fstab?
>

You are right, I was fooled by other code in rc.sysinit before
actually checking. Still it means some room for improvements, doe not
it? :)

>> So after switching to systemd user is suddenly presented with password
>> requests which (s)he never expected before. Nor are those password
>> requests necessary, as these encrypted containers may be opened only
>> on demand, not even every time system is booted. And in case of shared
>> system user may not even know passwords for all units.
>
> I am not sure how else this should be working. The thing is that before
> you decrypt it you cannot know what file system a device contains. It is
> hence impossible to figure out which crypto disk you need to decrypt and
> which one you don't. Or to be more explicit: if you have a line with
> LABEL=foo in fstab, how are you supposed to find the fs with this label
> in its superblock without actually having decrypted it? As long as you
> see only encrypted devices there is no way to figure out their UUID or
> LABELs.
>

The only reason to use LABEL or UUID is because you do not know how
your device will be named next time you boot. With device mapper
devices naming is completely predictable. Arguably there is absolutely
no reason to use LABEL with crypto devices; using
/dev/mapper/container is pretty much enough.

>> So removing default WantedBy=cryptsetup.target results in expected
>> (well, compatible) behaviour - cryptsetup unit is implicitly pulled in
>> by mountpoint (I have not tried swap but I assume it is the same) if
>> this mount point is auto-mounted on startup.
>
> No, this doesn't work, see above.
>

it depends, see above :)

So may be systemd could offer boot trime optimization thus encouraging
distributions to change from LABEL/UUID on encrypted devices (assuming
anyone is using it that is) to using device names?

Does something like this make sense:

- if crypto device name is present in /etc/fstab, do not add
dependency on crypto.taget, rather rely on target being auto-pulled by
corresponding mount unit?

This also adds additional advantage by allowing to display file system
name in password prompt. Currently prompt is mostly useless - I have
on my test VM dozen of hard disks all with identical ID_MODEL - so I
have no way to know which one is prompted for.

And if we ever have redirection from mount to systemd for mounting
file systems (present in fstab at least) this will also work
transparently after boot as well ...