| Summary: | Adding pre-encrypted partition fails to create correct cryptkey and crypttab files in /etc | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Gene Alexander <subs> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins |
| Version: | Cauldron | Keywords: | NEEDINFO |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | drakxtools-curses | CVE: | |
| Status comment: | |||
|
Description
Gene Alexander
2012-05-21 22:04:18 CEST
Gene Alexander
2012-05-21 22:06:09 CEST
Summary:
Adding pre-encrypted partition fails to create correct cryptkey and ccrypttab files in /etc =>
Adding pre-encrypted partition fails to create correct cryptkey and crypttab files in /etc Why bother with encryption, if the key is stored on the disk in plain text? I've never seen any mention of /etc/cryptkey in any script, man page, etc. When an encrypted filesystem is to be mounted at boot, the system should be asking the user for the passphrase, and using the entered passphrase as the key. In a sysvinit system, that's handled by /etc/rc.d/rc.sysinit. In a dracut system, that's handled by the initrd using scripts from tree -if /usr/lib/dracut/|grep crypt CC:
(none) =>
davidwhodgins (In reply to comment #1) ... > When an encrypted filesystem is to be mounted at boot, the system should be > asking the user for the passphrase, and using the entered passphrase as the > key. > > In a sysvinit system, that's handled by /etc/rc.d/rc.sysinit. > > In a dracut system, that's handled by the initrd using scripts from > tree -if /usr/lib/dracut/|grep crypt If this is how it is supposed to work after adding an encrypted partition with diskdrake and it did work that way that would be great. But no prompt to mount the encrypted /home partition on the PC in question appears during boot, and so it is not mounted on boot. Therefore the end-user has no access to his account on /home after boot. He would have to futz around as root first to get that done, which is not a desired option in this case. I would very much like to know how to make this work the way you suggest, as I too thought storing the key on the system was a bit dimwitted. But that is the only *working* solution, that works with Mga(1|2), I could find in a web search about mounting encrypted partitions under Linux during boot. Did you create the encrypted filesystem during the installation? If so, what did iso did you boot from? If you created it after the install, with the encrypted filesystem mounted, you need to run (as root) "dracut -f" without the quotes, so that dracut will add the needed scripts to the initrd. As I recall, and this has been a few weeks, it was created during installation. The install disk was Mageia 1 DVD burned from the mageia-dvd-1-x86_64.iso file. Here is another wrinkle to the problem that I just remembered. The end-user travels and will *need* remote access to this PC for up to six weeks at a time. Remote access is a must for this system along with the requirement that /home be encrypted. Upon a power event where his UPS shuts down the PC and then it comes back up while he is away, how will this work for him if the system is waiting for someone to type in a passkey to mount the encrypted partition? There will be no one at the location to do this at these times. I am not sure how to resolve the two problems. I would not have the system startup try to mount it then. Delete the crypttab and any fstab entry. Take a look at http://ody.ca/~dwhodgins/Luks-Howto.html particulary section 5. That's what I use, but instead of encrypting the entire /home filesystem, I use symlinks in my home directory such as Documents -> /var/mnt/data/Documents/ Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja Keywords:
(none) =>
NEEDINFO I would say, based on my conversation with Dave, the bug as posted is invalid. I need to rethink how to post this though. The creation of an internal encrypted /home *should* cause the PC to prompt to mount it in the boot phase. But that was not my experience when creating the mount for a client. The disk GUI used under MCC to create the encrypted /home partition apparently did not run the process to cause the system to ask for a pass key during boot. That should be examined and fixed if this is consistent behavior. We are now revisiting the client's encryption idea and discussing using a mount in /home/user/blah or external, removable drive/media such as an external USB hard drive or USB flash drive. These would be created using the GUI, but the need to prompt to mount them on boot would be out of the picture entirely. closing then Status:
NEW =>
RESOLVED |