[systemd-devel] cryptsetup units are actuvated by default

[Lennart Poettering]

On Mon, 14.02.11 08:45, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> > 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? :)

Well, but major changes in behaviour might not be advisable. 
> 
> >> 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.

Well, I think it's a good thing to mount by uuid, even if things happen
to reside on dm. I think it is a good idea to not bind our higher levels
of the stack unnecessarily to layers much lower.

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

Hmm, I am not necessarily convinced this is even a good idea. Dunno.

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

Hmm, not convinced. A mount point might not be the only reason why a
device is needed? And fstab is not the only place for mounts to be
configured? Dunno. I think the right answer to this problem is "noauto",
since things become deterministic by that. Otherwise things might become
fragile since depending on the configuration of one "consumer" of a device
(i.e. the mount) the system behaviour for *all* "consumers" would
change. 

Also, this would be quite a deperature from the current behaviour.

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

Yupp, this is a valid point. We probably should change our cryptsetup
implementation to use the eventual mount point name if there is one and
only fall back to ID_MODEL if we cannot figure it out.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.