Re: partman-auto-crypto
On Sat, Aug 19, 2006 at 11:20:03PM +0200, Frans Pop wrote:
Hi David,
Glad to see you back from holidays.
One general note: we really do have to be careful with this. As we are now
working towards RC releases of d-i, we cannot afford to implement really
risky changes.
Understood
The initial feedback from beta 3 shows there is still some work to do on
partman-crypto itself, so I'm fairly happy we made the decision to not
offer p-a-c yet. There are also some important open issues for LVM
itself. I'd rather spend energy on perfecting the base functionality than
on adding p-a-c if we have to choose what to do before Etch.
I agre that it was good to have partman-crypto alone in beta3, it
generated much more feedback and it seems that most issues have been
resolved.
As far as I know, the major outstanding issue is that of keyboard
input. Currently it seems that d-i does not allow UTF8 input which means
that passphrases with non-ascii characters won't work after reboot into
the newly installed system.
So it would really be nice to have a fix for #365308 which has been open
since April and affects other parts of d-i as well (such as username
input).
Oh, and we need a more thorough check for unencrypted swap.
Are you aware of any other major partman-crypto issues not in the BTS?
As for lvm, I don't see any new bugs against partman-lvm, what issues
are you referring to?
I'd also very much hate it if we would find we had important regressions
in partman for RC1 because of rushing implementation of p-a-c and
partman-auto RAID support.
There is always post-Etch to implement major new features...
Another alternative is to not change the partman-auto main menu at all.
The menu might get crowded but that is mostly an issue with > 2 disks
which is not a very common scenario. This would allow p-a-c to be added
without any changes (the issue of overcrowding is orthogonal to p-a-c
IMHO, p-a-c just makes the problem more immediate).
This was my original plan before you brought up the issue of crowding
the menu :)
On Saturday 19 August 2006 20:56, David Härdeman wrote:
1) Swap on LVM in partman-auto-lvm
I sent an RFC on this more than a month ago. Not much discussion
resulted, I got a few positive comments and no negative comments. Is
this ok to commit?
Yes, I would say it is OK to enable that ASAP, at least on a trial basis.
Ok, will commit today
2) Concerns over an overcrowded partman-auto menu
FJP suggested in the RFC thread on partman-auto-crypto that the
partman-auto main menu might need to change to accomodate the large
number of options. The following example was given:
[...]
However, I think that we should split it into two screens:
I have been thinking about this a bit too and I agree this is probably
better.
Note that there is one more option that needs to be accommodated:
Use largest available free space (or something like that)
That option is only shown if there is free space on a disk and is
currently only supported for standard partitioning.
There can in theory be multiple disks that have free space you could
choose from. Maybe it would be good to explicitly show the free space
blocks and their sizes on the next dialog instead of blindly selecting
the largest.
If you select "Erase disk and create new partitions" you'd then get:
<example>
Please select the disk to erase:
SCSI1 (0.0.0) (sda) - 2.1 GB VMware, ...
SCSI2 (0.0.1) (sdb) - 2.1 GB VMware, ...
SCSI2 (0.0.1) (sdc) - 2.1 GB VMware, ...
</example>
This screen could probably either be skipped or, better, replaced by a
message warning which disk will be used if only one disk is detected.
Have to work out how that would work with preseeding though.
I think we could in fact have three levels of screens with the last one
being along the lines of "Warning: the content of disk(s) X, Y and Z is
going to be erased. This means that the data will be permanently
lost..etc..etc..etc..etc. Do you want to continue?".
So for scenarios where there is only one disk, we skip screen two and go
directly to screen three.
The third screen can then be preseeded to "accept" or you can leave it
as is which will give a final warning to the user even if preseeding is
used for the method and disk to use (this will of course be up to the
preseeding recipe used).
Where you can select a single disk, whereas the "Erase disk(s); use LVM
for new partitions" would show:
<example>
Please select the disk(s) to erase and use with LVM:
[*] SCSI1 (0.0.0) (sda) - 2.1 GB VMware, ...
[ ] SCSI2 (0.0.1) (sdb) - 2.1 GB VMware, ...
[ ] SCSI2 (0.0.1) (sdc) - 2.1 GB VMware, ...
</example>
This allows multiple disks to be used for LVM or RAID and should
simplify the preseeding to use two values: method and disks to use.
What RAID level(s) are you assuming/wanting to support here?
I'm not involved in the RAID part of partman, but I'd assume that levels
0, 1 and 5 would be offered.
I guess you have seen the commit by Simon Huggins to support RAID1? It
would be great if that could be integrated with this.
Yes, I've noticed it but not gone through it in detail. If I understood
things correctly, it adds preseeding support but no UI for manual setup?
It should be easy to do so though, and I could probably help Simon with
it if necessary.
Not something that is very important to me though, as long as some
progress can be made on adding partman-auto-crypto :)
Without yet having looked at the code...
For p-a-c, what I have been wondering about is which partitions should be
encrypted by default for the different schemes. From comments in earlier
threads I understand that having e.g. /usr encrypted isn't all that
useful.
Right now, all partition but /boot are encrypted. What happends is that
/boot is created and then one large partition. That large partition is
dm-crypt mapped an the dm-crypt device is used as a LVM PV. All other
partitions are LV's in that LVM PV. This allows for one password during
boot to setup all encrypted partitions.
So there are two benefits as I can see it to having /usr encrypted:
Allows /usr to be managed with the LVM tools as well
Avoids any accidental disclosure of information, e.g. there is
/usr/local which may contain something of interest. Or the user may not
want it to be known even which programs he has installed.
The disadvantage is of course performance.
I think we should err on the side of caution and encrypt everything by
default.
So what partitions does p-a-c set up encrypted currently? I could imagine
something like ("<c>" indicates encryption):
"atomic": / <c>, /boot, swap <c>
"home": /, /boot, /home <c>, swap <c> (so, / not encrypted)
"multi": /, /boot, /tmp <c>, /usr, /var <c>, /home <c>, swap <c>
(maybe / should be encrypted too in this case)
I would definately encrypt / as well. /etc usually contains a lot of
good information for an attacker (e.g. /etc/shadow).
This could be set in the recipes fairly easily by using a "$encrypt { }"
flag or something for partitions to be encrypted.
Yes, wouldn't be hard to add
Something like this would possibly be needed anyway for arches that have
special bootloader partitions (see for example the "palo" partition in
recipes-hppa). Or do you already have a different method for dealing with
those?
Right now all partitions which are marked as $lvmok { } are encrypted. I
assume that "palo" partitions and other special partitions aren't marked
as $lvmok?
Take care when uploading. I'm not sure the committed auto-RAID stuff is
ready yet.
I wont upload anything before I have an ok from you
Regards,
David
Reply to: