Jürgen Pabel wrote: > > Interesting idea. I wonder whether those separate key files per user > > are worth the effort though. LUKS has eight key slots so when > > reserving one for the admin you still have seven left for users. > > Have you considered simply storing a mapping of user names to key > > slots? > > Well, one of the major reasons was that it eliminates this limit > (although I agree that it's usually not really limit with practical > implications). > > Another reason is that tokentube allows for different deployment options: it's > possible to configure the system in such a way that the user's auth files (key > files) are in fact owned by the user. That's not a common scenario but I've > seen environments which required such setups. Wouldn't that expose the master key to the users? > > Also, as long as you're using local authentication you don't need to > > store the password for pam authentication. Should be sufficient to > > just reconfigure the displaymanager to auto login the user that > > unlocked the root device. > > True, but that requires "raw" device access (instead of "working" at the > filesystem layer) - which most often requires root (or at least appropriate > group) privileges for accessing the "raw" device during execution (like via > setuid'ing the binary). The password is changed via pam module which typically runs as root anyways (/usr/bin/passwd is usually setuid root). Also I expect e.g. DeviceKit to add a luks key change method sooner or later which wouldn't require direct device access by the user either. > All in all, I think it's a "clean" solution for the stated problem. Well, if the slot limit is no problem the tokentube way looks rather complex to me :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
