[systemd-devel] cryptsetup units are actuvated by default

[Lennart Poettering]

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?

> 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.

> 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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.