Milan Broz wrote: > On 10/22/2009 04:16 PM, Ludwig Nussel wrote: > > There's no way to determine whether e.g. the keymap on the console is > > the same as in X. Ie a key with umlauts added in an xterm may not be > > usable during boot. So when using e.g. an encrypted root partition > > users could lock themselves out. So I wonder whether a patch like > > the following would be acceptable? > > > + "* Warning: Entering non-ASCII passwords\n" > > + "* may not be possible on all systems.\n" > > + "* Make sure you can unlock the volume in\n" > > + "* the intended environment!\n"); > > I don't think this in good idea. Information that user entered non-ASCII > character is useful for attacker, why display it to terminal? > (That problem exist in all password entry dialogs - why cryptsetup should > be special here?) It's only displayed if you add a new password. I doubt you usually do that if someone's looking at your screen. He could just look at your keyboard while you are typing as well then, right? :-) Anyways, if that's a concern for you the warning could be displayed unconditionally before prompting for a password. > This should be solved in environment before cryptsetup starts - set proper > keymap (even during boot). IIRC Fedora support setting keymap in boot environment now, > there were similar bug reports already:-) I agree, but that only solves part of the problem. Nowaday users apparently are encouraged to use desktop apps to change the keymap for their session (no system wide xorg.conf anymore). There's no relation between console keymap and X keymap. So if one uses cryptsetup in an xterm to enter umlauts there's no way to guarantee that the password will work in initrd, even if initrd supports keymaps. I suppose in all distros the console and X keymaps are the same after installation as the installer sets a proper default so one could argue that the above situation is unlikely. However the guy who complained to me is pre-installing systems for his customers. So there's a chance that he uses a different keyboard layout for installation than his customer later. I've convinced him to tell his customers about the problem but I still think it's a mean trap. Calling people morons because they didn't read the manpage thoroughly worked when encrypted root was a feature for freaks but now it's only a matter of enabling a checkbox. > Also I expect that in future libcryptsetup will be used more (instead > of wrapper over cryptsetup binary and the whole internal code > for reading password will be moved to caller application which is then responsible > for password from terminal reading stuff. Frontends will have to implement the same warning then. 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
