[systemd-devel] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts.

[Przemyslaw Rudy]

Hello Lennart
Sorry, I missed that mail...

Beside referring to the bugzilla description I could simplify
the usecase to this:
- prepare e.g. /home on luks, use 2 keys: passphrase and key-in-file
- put the key file on usb stick
- start machine without usb stick inserted
- it won't ask for passphrase and so won't boot

With the bugfix (and related /fstab x-timeout entry for ubs stick) it
will correctly ask for the passphrase when usb stick is not in.

Actually I'm out of time and cannot spent more time on this. I could
change the code as suggested but cannot test it then and I
don't want to send untested patch.

The bug in systemd dependency is already localized and the bugfix
solution code is provided, feel free to use it, re-implement/change/drop
as you wish.

Regards
Przemek



On 07/03/2014 01:36 PM, Lennart Poettering wrote:
> On Sun, 25.05.14 12:39, Przemek Rudy (prudy1 at o2.pl) wrote:
> 
>> -Set *manager_get_units_requiring_mounts_for(Manager *m, const char *path) {
>> +Set *manager_get_units_need_mounts_for(Manager *m, const char *path,
>> bool strong) {
> 
> Please don't invent new bools halfway. Please always use the same logic
> here to discern the two kinds, i.e. the dep type enum.
> 
>>           * them. It's a hashmap with a path string as key and a Set as
>> -         * value where Unit objects are contained. */
>> -        Hashmap *units_requiring_mounts_for;
>> +         * value where Unit objects are contained.
>> +         * [0] - map of required (strong) paths
>> +         * [1] - map of wanted (weak) paths */
>> +        Hashmap *units_need_mounts_for[2];
> 
> Please use two normal variables for this. Two isn't that many that you'd
> need to defer to an array for this. Also, an array where we use
> arbitrary numeric indexes for reference two different concepts is not
> OK. If we do this, then we must have an enum to reference this. Also,
> introducing a new numbering scheme, where we already have the dep type
> as enum...
> 
> Generally, I still don't really feel that the usecase for this is strong
> enough. Can you make a strong concise case why we want this? I am not
> totally opposed, but I want to know why I merge this...
> 
> Lennart
>