Hi, > 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. > 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). All in all, I think it's a "clean" solution for the stated problem. jp _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
