Bug 1030416 - Reusing LVs from encrypted VG should have "Encrypted" checkbox forced on
Reusing LVs from encrypted VG should have "Encrypted" checkbox forced on
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-14 06:52 EST by Kamil Páral
Modified: 2015-04-14 16:39 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-14 16:39:22 EDT
Type: Bug
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 Kamil Páral 2013-11-14 06:52:12 EST
Description of problem:
This is something we discovered in bug 1008732 comment 14 and 17. Anaconda tries to have a dead simple partitioning editor. However, because it is not visually clear how partitions/VGs/LUKS etc are laid upon each other, there can easily be a confusion for users. Consider this use case:

1. An existing encrypted default Fedora installation is present on the disk. That means standard part /boot and LVM+LUKS with / and swap. The PV is encrypted, therefore the whole VG is encrypted.

2. A user wants to create a completely new and clean disk layout. In the initial dialog he picks "Partition scheme: LVM" and does not check "Encrypt my data". Then enters Custom part.

3. In custom part he clicks on the existing encrypted installation and unlocks it. Why not. Just to have a look.

4. Now he sees all his current partitions. Heureka! He realizes that he doesn't have to define his new layout by hand, he can reuse the existing layout and tweak it a bit. How simple.

5. He reformats and reuses /boot and swap. For swap, the "Encrypt" option is unchecked by default and he leaves it unchecked.

6. He reformats and reuses / (maybe adjusts the size a bit, if he needs). Then he decides to enable the "Encrypt" option to have his data safe.

7. He proceeds with installation.

His expectations of the new layout were (and anaconda didn't suggest otherwise):
/dev/sda1  /boot
/dev/sda2  PV
             -> VG
                  -> LV swap
                  -> LV LUKS
                        -> /


His real layout will be:
/dev/sda1  /boot
/dev/sda2  PV LUKS
                  -> VG
                       -> LV swap
                       -> LV LUKS
                             -> /

Please note that if he didn't use the same password for / encryption as in the previous installation, then the two LUKS areas have a _different_ password! He might not be able to boot to the new system at all, if he doesn't try out all his passwords.


The major problem here is that he reused LVs from an encrypted VG, but anaconda displayed them as unencrypted (Encrypt option was off). Therefore the user assumed that those partitions would become unencrypted (remember, he doesn't know the technical details). As a side note, the VG properties couldn't be adjusted or even displayed (the whole widget is grayed out). Moreoever, when actually choosing encryption, anaconda created double-encrypted disk (PV and LV).


Proposed solution:
If the user uses encrypted VG, no matter whether he created the VG by hand or reused and old one, display all its LVs with "Encrypted" option checked and unmodifiable (grayed out). That will be a strong hint for the user that this LV can't be "converted" to an unencrypted LV. Also it might make him realize that the encryption settings are configured elsewhere - in the VG dialog.
This will improve the clarity of anaconda partition editor for both skilled and unskilled users.


Version-Release number of selected component (if applicable):
Fedora 20 Beta
anaconda 20.25.6

How reproducible:
always

Steps to Reproduce:
1. follow the description
Comment 1 Kamil Páral 2013-11-27 13:47:19 EST
danofsatx on IRC came with this setup ("anaconda did it, I don't know why"):

NAME                                              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                                 8:0    0 111.8G  0 disk  
├─sda1                                              8:1    0   150M  0 part  /boot/efi
├─sda2                                              8:2    0   300M  0 part  /boot
└─sda3                                              8:3    0 111.4G  0 part  
  └─luks-e4a7ccd5-a71a-40ab-8263-1564f500d3a3     253:0    0 111.4G  0 crypt 
    ├─fedora_fc20-root                            253:2    0  98.5G  0 lvm   
    │ └─luks-74b537d3-f908-4191-857f-79093a5ae74a 253:5    0  98.5G  0 crypt /
    ├─fedora_fc20-swap                            253:3    0  11.7G  0 lvm   
    │ └─luks-13c37d96-8b3b-46ac-a76c-2f013d8d848c 253:4    0  11.7G  0 crypt [SWAP]
    └─fedora_fc20-home                            253:6    0 932.6G  0 lvm   
      └─luks-d4772964-0e98-4a3d-9a07-a7358112ab87 253:7    0 932.6G  0 crypt /home
sdb                                                 8:16   0 931.5G  0 disk  
└─sdb1                                              8:17   0 931.5G  0 part  
  └─luks-51bb2bdb-4ba1-4716-a48f-c01c11a89257     253:1    0 931.5G  0 crypt 
    └─fedora_fc20-home                            253:6    0 932.6G  0 lvm   
      └─luks-d4772964-0e98-4a3d-9a07-a7358112ab87 253:7    0 932.6G  0 crypt /home
sr0                                                11:0    1  1024M  0 rom   


This could be related to this issue. Anaconda should not allow to easily set both VG and LV encryption at the same time.
Comment 2 Chris Murphy 2013-12-18 22:52:50 EST
Is this fixed? Bug 1038969 comment 13 suggests it is, and maybe was fixed with this patch: https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-December/007760.html
Comment 3 David Shea 2015-04-14 16:39:22 EDT
The encrypt checkbox on the partition is checked in this case now.

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