Bug 472594 - [RFE]: allow anaconda to create Logical Volume before encrypting .....
[RFE]: allow anaconda to create Logical Volume before encrypting .....
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-21 16:55 EST by Tom London
Modified: 2008-11-24 19:52 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-24 19:52:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom London 2008-11-21 16:55:21 EST
Description of problem:
Not 100% sure about this, sorry if this is noise: did I just not click the right buttons during install.....?

From tracing through an F10Spin2 install that set up an encrypted root, it appears that anaconda first "sets up" the encrypted partition, and then "sets up" the LVM (VolGroup00/LogVol00).

I think this means that I cannot "extend" VolGroup00-LogVol00 by adding PVs from another partition and still have the encryption enforced on "root".  Do I have that right?

Would it be any less secure to reverse the above order, and "set up" the LVM/VG first, followed by the cryptsetup of the LogVol00?  Or is there a chicken and egg problem here?

From reading /etc/rc.d/rc.sysinit, I think this would "work" on boot, since it looks like rc.sysinit calls 'init_crypto' twice, once before and once after running 'vgchange -a y ....'

Or is there a simpler way to do this..... 


Version-Release number of selected component (if applicable):
anaconda-11.4.1.62-1.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 David Lehman 2008-11-21 17:48:38 EST
You can either encrypt the physical volumes or you can encrypt the logical volumes. Which you do is up to you if you do a custom partition layout. If you choose to have anaconda create the encrypted default layout, you get encrypted physical volumes (not encrypted logical volumes).

Whatever device is encrypted must be encrypted before it can be set up as an LVM component or a filesystem or whatever. You can't go backwards.

In either case you can add PVs to your VG, regardless of whether your existing PVs are encrypted or your LVs are encrypted.
Comment 2 Tom London 2008-11-21 18:14:56 EST
Thanks for the response.

Here's the scenario I am considering:

I have installed using the "let anaconda set up the partitions in the free space" method on a drive with 2 previously formatted NTFS partitions. 

I check the "encrypt" box. 

I have the following partitions as reported by parted:

Disk /dev/sda: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  22.0GB  22.0GB  primary   ntfs         boot 
 2      22.0GB  63.4GB  41.4GB  primary   ntfs                
 3      63.4GB  63.6GB  206MB   primary   ext3              
 4      63.6GB  160GB   96.4GB  extended                    
 5      63.6GB  160GB   96.4GB  logical                lvm  

[Of course, this is reported after the system is booted.]

At a later point, I would like to zero out /dev/sda2, run pvcreate on it, and add it to VolGroup00 (in /dev/sda5), and then to LogVol00 to increase the size of my root filesystem.

But "cryptsetup status" reports:

[root@tlondon ~]# cryptsetup status /dev/mapper/luks-cc25f1b4-d5be-4622-a5be-955e007c2356 
/dev/mapper//dev/mapper/luks-cc25f1b4-d5be-4622-a5be-955e007c2356 is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 128 bits
  device:  /dev/sda5
  offset:  1032 sectors
  size:    188280705 sectors
  mode:    read/write
[root@tlondon ~]# 

So LUKS is managing encryption for sda5, not VolGroup00 or LogVol00.  So if I add PVs created in sda2 to them, I think LUKS won't encrypt.  

I can add the PVs, but if the above it right, data stored in them won't be private, unless I set up a second LUKS key/etc. for it.

I was hoping I could "just add the PVs" and have it secured with the "anaconda created" crypto. I thought that would be possible if the "/dev/mapper/VolGroup00-LogVol00" device was encrypted (and then resizing the cryptsetup after adding the PVs).

If the above is just crazy, I suppose I could do a "luksFormat/luksOpen" on the new device (/dev/sda2) before I do the pvcreate/vgextend/lgextend/ext3-resize.  But now boot will require 2 passphrases, ....

Am I going down a "bad path" here thinking it would be useful to be able to "extend"?
Comment 3 David Lehman 2008-11-21 18:23:19 EST
You can just use the same passphrase for sda2 that you use for sda5. Run luksFormat, specify the same passphrase, then run luksOpen, then pvcreate on the mapped device (eg: /dev/mapper/<something>).

If this affects the VG containing the root filesystem or your first (per fstab) swap device, make sure you re-run mkinitrd or you won't be able to boot next time.


For some info about managing LUKS devices: 

  http://fedoraproject.org/wiki/Docs/Drafts/DiskEncryptionUserGuide
Comment 4 Tom London 2008-11-21 18:31:43 EST
Thanks.  I'll study this, and probably close this in a few days.

Perhaps I'll be more thoughtful on my next install ;)
Comment 5 Tom London 2008-11-24 19:52:48 EST
OK.  I'll close this, and try LVM install next....

Note You need to log in before you can comment on or make changes to this bug.