[arch-projects] [RFC 00/23] Encrypted volume work
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:21 PM, Matthew Monaco
I don't really like this, it would be better to check only for cryptsetup here, other checks can go where they're used or not at all.
The best might be to not do anything like this at all.
I'm not a big fan of this. Just deal with errors properly where they might happen (as other things than a missing binary might go wrong). If you are confident that this warning will give no false positives (i.e. warn about missing stuff which actually does not matter), then it's fine, but I don't think it is worth the effort. -t
On 05/18/2012 04:09 PM, Tom Gundersen wrote:
On Fri, May 18, 2012 at 6:21 PM, Matthew Monaco
wrote: I don't really like this, it would be better to check only for cryptsetup here, other checks can go where they're used or not at all.
The best might be to not do anything like this at all.
I'm not a big fan of this. Just deal with errors properly where they might happen (as other things than a missing binary might go wrong).
If you are confident that this warning will give no false positives (i.e. warn about missing stuff which actually does not matter), then it's fine, but I don't think it is worth the effort.
-t
(Given the commit message) that's enough convincing for me =)
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:21 PM, Matthew Monaco
From: Matthew Monaco
--- cryptmount.sh | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/cryptmount.sh b/cryptmount.sh index 03b8575..41b713c 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -203,6 +203,9 @@ ct_read_crypttab() { -|none|"") key=- ;; + /dev/random|/dev/urandom) + options="$options,%random" + ;;
You probably want to tag /dev/hw_random as well, in case someone decides to use a real random generator.
/*|UUID=*|PARTUUID=*|LABEL=*) : ;; -- 1.7.10.2
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
From: Matthew Monaco
Without any arguments, use crypttab. Otherwise try to unmap whatever is given on the command line. This does not support automatically unmapping volumes which are not in crypttab.
One FIXME might be that when using crypttab, volumes should be handled in the reverse order.
Hopefully the order should not matter (except when encrypting encrypted devices!), but I agree that in principle -U should be the dual of the normal operation so doing the unmappings in reverse makes the most sense. -t
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
Without udevd, it is unlikely that new devices are going to show up. So we will know not to wait for them.
Suggested-by: Dave Reisner
NACK. I'm probably missing the point here (as I was a bit suspicious about waiting for devices in the first place), but I don't think this makes sense. Two cases where a missing udev means you won't get more devices: 1) If you reference them by symlinks in /dev/disks/by-* 2) If the required module is not built in to the kernel and udev is needed for modprobing it. However, you might very well have built your usb-drivers into the kernel, referenced them as /dev/sdc1 (or whatever) and need to wait for them to appear. Remember that udev no longer populates /dev with devicenodes as this is done by the kernel. Am I missing something? -t
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
With the exception of some special values, convert the comma separated list of options to pass directly to cryptsetup. This means we don't have to explicitly support all of cryptsetups options.
If at all possible, I think it is better to explicitly handle the things we want to support. Passing on the options blindly means that we are tightly coupled to the underlying tool (which is for instance what made the transition from net-tools to iproute so painful). Maybe one solution could be to handle the things we want to support, and for the sake of backwards compatibility we do your catch-all matching at the end, but print a warning "Passing unrecognized options to cryptsetup"?
'size' and 'device-size' are needed because (yes) systemd and Debian use size for cryptsetup's --key-size option. "cryptsetup --size create" limits the size of a device.
'swap' means run mkswap after mounting, this is standard as far as the Debian and systemd format goes.
'luks' and 'plain' are also used by Debian and systemd, but they seem like superfluous configuration because "cryptsetup isLuks" gives this information.
'noauto' will work with the default $FILTER (-O) of !noauto
'tmp' is supported by Debian and systemd. This will come in a later commit.
There is also list of options which are supported by Debian that we'll ignore.
It should be pointed out that in this context "Debian+systemd" essentially means "everyone else". Also, we don't "need" to deal with these options, but I absolutely agree that we should (even if all we do is warn that the option is not supported). I think we should aim for: 1) a crypttab file copied from another distro to Arch should do something sensible (hopefully work, but at least give reasonable error messages) and 2) a crypttab file that works without warnings on Arch should work just fine when copied to another distro.
--- cryptmount.sh | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)
diff --git a/cryptmount.sh b/cryptmount.sh index 55a6944..7e89bbc 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -149,6 +149,17 @@ ct_main() { info "udevd not running, or unable to detect it: waiting for devices disabled" fi
+ # Pre-parse OPTIONS, a little ugly, but it works + preparse() { + local args swap + if ! ct_parse_options $OPTIONS; then + error "Invalid options string: $OPTIONS" + exit 1 + fi + OPTIONS="$args" + } + preparse + if [ -z "$action" -o "$action" = "list" ]; then
if [ $# -ne 0 ]; then @@ -359,6 +370,64 @@ ct_resolve_device() { return 1 fi } + +ct_parse_options() { + + local IFS=',' optlst="$*" opt key val + + for opt in $optlst; do + + # separate key and value + unset key val + case "$opt" in + "") + continue;; + *=*) + key="${opt%%=*}" + val="${opt#*=}" + [ "$key" = "$val" ] && unset val + ;; + *) + key="$opt";; + esac + + case "$key" in + swap) + # set external variable + swap=1 + ;; + luks|plain) + warn "Ignoring option $key, LUKS volumes are automatically detected" + ;; + noauto|%*) + : + ;; + skip|precheck|check|checkargs|noearly|loud|keyscript) + warn "Ignoring Debian specific option '$key'" + ;; + tmp) + warn "The tmp= option is not supported" + ;; + size) + args="$args --key-size $val" + ;; + device-size) + args="$args --size $val" + ;; + *) + if [ ${#key} -eq 1 ]; then + args="$args -$key $val" + else + args="$args --$key $val" + fi + ;; + esac + + done + + return 0 +} + # # # ---------------------------------------------------------------------------- #
-- 1.7.10.2
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
Currently in rc.sysinit we check that blkid returns 2 before running mkswap. This is a little bit stronger. Even without mkswap "cryptsetup create" can be dangerous, so do the blkid check for all plain (non-LUKS) mappings. Furthermore, just check for a non-zero return status, if this is too broad we can get more specific.
I think you reverted the check. It used to be "if blkid returns 2 overwrite the device" now you do "if blkid returns 0 we can overwrite the device".
Note: A user can still destroy her data if she enters the wrong password for a cryptsetup create. This we'll leave as the user's fault; she should be aware of the limitations of a plain mapping and the --verify-passphrase cryptsetup option. --- cryptmount.sh | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/cryptmount.sh b/cryptmount.sh index d602043..03699d0 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -1,6 +1,6 @@ #!/bin/sh
-SHORTOPTS="LMUc:w:nqvho:O:" +SHORTOPTS="LMUc:fw:nqvho:O:" DEPS="cryptsetup blkid findmnt mkswap mktemp" UDEVRUNNING=0
@@ -10,6 +10,7 @@ WAITTIME=10 CRYPTTAB=/etc/crypttab OPTIONS= FILTER="!noauto" +FORCE=0
ct_print_usage() { cat <<__EOF__ @@ -32,6 +33,8 @@ usage: $0 [OPTIONS] [-L]
options: -c FILE set the crypttab location (default: /etc/crypttab) + -f force destructive operations even when a block device appears to + contain data
As this is a bit dangerous stuff, it might be best to not have an -f option, but rather advice the user to use wipefs manually. Or are there situations where we really must force cryptsetup, but cannot run wipefs first?
-w NUM wait time (seconds) for a device if it is not already available -n dry run -q decrease verbosity @@ -115,6 +118,7 @@ ct_main() { M) set_action map;; U) set_action unmap;; c) CRYPTTAB="$OPTARG";; + f) FORCE=1;; w) WAITTIME=${OPTARG//[!0-9]};; n) DRYRUN=1;; q) LOGLEVEL=$(( LOGLEVEL - 1 ));; @@ -381,7 +385,14 @@ ct_map() {
info "device '$dev' assumed to be plain"
- if run cryptsetup create $key $args "$name" "$dev"; then + # cryptsetup 'create' can be destructive, don't do it if blkid can + # identify the device type + if [ $FORCE -ne 1 ] && blkid -p "$dev" &>/dev/null; then + error "Refusing to call 'cryptsetup create' on device that might" + error " have data. If you are sure this is what you want, use" + error " the -f option" + ret=1 + elif run cryptsetup create $key $args "$name" "$dev"; then info "sucessfully mapped '$dev' to '/dev/mapper/$name'" if [ $swap -eq 1 ]; then if run mkswap -f -L "$name" "/dev/mapper/$name"; then -- 1.7.10.2
On 05/18/2012 05:03 PM, Tom Gundersen wrote:
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
wrote: Currently in rc.sysinit we check that blkid returns 2 before running mkswap. This is a little bit stronger. Even without mkswap "cryptsetup create" can be dangerous, so do the blkid check for all plain (non-LUKS) mappings. Furthermore, just check for a non-zero return status, if this is too broad we can get more specific.
I think you reverted the check. It used to be "if blkid returns 2 overwrite the device" now you do "if blkid returns 0 we can overwrite the device".
I changed the check, but I don't think I reversed it. It's now: Iff blkid returns 0, we can't overwrite. Regardless, I think this was a bad decision on my part, blkid can error for some other reason and we don't want to allow an overwrite, I'll fix for checking '2' again.
Note: A user can still destroy her data if she enters the wrong password for a cryptsetup create. This we'll leave as the user's fault; she should be aware of the limitations of a plain mapping and the --verify-passphrase cryptsetup option. --- cryptmount.sh | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/cryptmount.sh b/cryptmount.sh index d602043..03699d0 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -1,6 +1,6 @@ #!/bin/sh
-SHORTOPTS="LMUc:w:nqvho:O:" +SHORTOPTS="LMUc:fw:nqvho:O:" DEPS="cryptsetup blkid findmnt mkswap mktemp" UDEVRUNNING=0
@@ -10,6 +10,7 @@ WAITTIME=10 CRYPTTAB=/etc/crypttab OPTIONS= FILTER="!noauto" +FORCE=0
ct_print_usage() { cat <<__EOF__ @@ -32,6 +33,8 @@ usage: $0 [OPTIONS] [-L]
options: -c FILE set the crypttab location (default: /etc/crypttab) + -f force destructive operations even when a block device appears to + contain data
As this is a bit dangerous stuff, it might be best to not have an -f option, but rather advice the user to use wipefs manually. Or are there situations where we really must force cryptsetup, but cannot run wipefs first?
No comment here, I just added -f as a convenience.
-w NUM wait time (seconds) for a device if it is not already available -n dry run -q decrease verbosity @@ -115,6 +118,7 @@ ct_main() { M) set_action map;; U) set_action unmap;; c) CRYPTTAB="$OPTARG";; + f) FORCE=1;; w) WAITTIME=${OPTARG//[!0-9]};; n) DRYRUN=1;; q) LOGLEVEL=$(( LOGLEVEL - 1 ));; @@ -381,7 +385,14 @@ ct_map() {
info "device '$dev' assumed to be plain"
- if run cryptsetup create $key $args "$name" "$dev"; then + # cryptsetup 'create' can be destructive, don't do it if blkid can + # identify the device type + if [ $FORCE -ne 1 ] && blkid -p "$dev" &>/dev/null; then + error "Refusing to call 'cryptsetup create' on device that might" + error " have data. If you are sure this is what you want, use" + error " the -f option" + ret=1 + elif run cryptsetup create $key $args "$name" "$dev"; then info "sucessfully mapped '$dev' to '/dev/mapper/$name'" if [ $swap -eq 1 ]; then if run mkswap -f -L "$name" "/dev/mapper/$name"; then -- 1.7.10.2
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
From: Matthew Monaco
The key field may be device:key:fstype or device:key in which case the device is resolved and mounted if necessary. For these, key must be relative to the root of the filesystem on the device.
The keydevice is mounted to $(mktemp -d). It is only unmounted if we mounted it.
This mounts your device to /tmp/<something>. Are we sure that we never overmount something on /tmp between we mount and unmount the device? I guess it would be safer to create a folder under /run (e.g. /run/cryptmount) and use that as --tmpdir when using mktemp. Or maybe I'm overly paranoid...
cryptmount.sh | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/cryptmount.sh b/cryptmount.sh index 03699d0..a8a0ec8 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -341,8 +341,8 @@ ct_unmap() {
ct_map() {
-<<<<<<< HEAD local name="$1" dev="$2" key="$3" args="" swap=0 + local key_dev="" key_fstype="" key_mntpnt="" key_dev_umount=0 shift 3
if [ -e "/dev/mapper/$name" ]; then @@ -363,8 +363,71 @@ ct_map() { return 1 fi
+ # parse various key formats + case "$key" in + *:*:*) + key_dev="${key%%:*}" + key="${key#*:}" + key_fstype="${key%%:*}" + key="${key#*:}" + ;; + *:*) + key_dev="${key%%:*}" + key="${key#*:}" + ;; + ""|-) + unset key_dev + unset key + ;; + *) + unset key_dev + ;; + esac + + # resolve any needed key device and mount if necessary + if [ "$key_dev" ]; then + + if key_dev="$(ct_resolve_device "$key_dev")"; then + + if key_mntpnt="$(findmnt -cfmnoTARGET "$key_dev")"; then + + key="$key_mntpnt/$key" + + elif key_mntpnt="$(mktemp -d)"; then + + [ -n "$key_fstype" ] && key_fstype="-t $key_fstype" + + if run mount -r $key_fstype "$key_dev" "$key_mntpnt"; then + key="$key_mntpnt/$key" + key_dev_umount=1 + else + error "unable to mount key device '$key_dev'," + error " falling back on interactive password" + unset key + fi + else + error "unable to find or create mountpoint for key device," + error " falling back on interactive password" + unset key + fi + else + error "key device '$key_dev' not found" + error " falling back on interactive password" + unset key + fi + + elif [ -n "$key" -a "$key" != "-" ]; then + + if ! key="$(ct_resolve_device "$key")"; then + error "key '$key' not found" + error " falling back on interactive password" + unset key + fi + + fi + if [ "$key" ]; then - key="--key-file=\"$key\"" + key=--key-file="$key" fi
local ret=0 @@ -409,6 +472,15 @@ ct_map() {
fi
+ # clean up after ourselves + if [ $key_dev_umount -eq 1 ]; then + if ! run umount "$key_dev"; then + warn "unable to mount key device '$key_dev'" + else + run rmdir "$key_mntpnt" + fi + fi + return $ret }
-- 1.7.10.2
From: Matthew Monaco
From: Matthew Monaco
The wording of these warnings might be a controversial, so just adding:
Acked-by: Tom Gundersen
From: Matthew Monaco
--- cryptmount.sh | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/cryptmount.sh b/cryptmount.sh index 59c6c78..3844e01 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -302,6 +302,15 @@ ct_read_crypttab() { /dev/random|/dev/urandom) options="$options,%random" ;; + ASK) + info "$CRYPTTAB:$lineno: ASK is a deprecated key, please use '-' or 'none'" + key=- + ;; + SWAP) + info "$CRYPTTAB:$lineno: SWAP is a deprecated key, please use '/dev/urandom' and the 'swap' option" + key="/dev/urandom" + options="$options,swap,%random" + ;; /*|UUID=*|PARTUUID=*|LABEL=*) : ;; -- 1.7.10.2
From: Matthew Monaco
Ack.
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
From: Matthew Monaco
Give a deprecation notice though. --- cryptmount.sh | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/cryptmount.sh b/cryptmount.sh index 3844e01..37f5121 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -421,6 +421,18 @@ ct_map() { key="${key#*:}" key_fstype="${key%%:*}" key="${key#*:}" + case "$key_fstype" in + *[!0-9]*) + :;; + *) + warn "<dev>:<offset>:<length> is a deprecated key format. Please use" + warn " the keyfile-offset and keyfile-size options instead. This" + warn " format will *soon* be removed from cryptmount/crypttab!" + opts="$opts --keyfile-offset=$key_fstype --keyfile-size=$key" + key="$key_dev" + unset key_fstype + unset key_dev + esac ;; *:*) key_dev="${key%%:*}" -- 1.7.10.2
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
It seems like some people use this. Use a new variable "tmpfs" to contain the file system type. Default to ext4 (Debian does this). Use the same variable to track the swap option too because we can only do one or the other.
For the record: I don't see the value of this, and think people should use a real tmpfs backed by encrypted swap. That said, if there is demand for it I won't object. Does Debian support choosing your own filesystem or do they always use ext4? Having this be configurable seems a bit over the top to me...
--- cryptmount.sh | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/cryptmount.sh b/cryptmount.sh index 37f5121..5320e3d 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -155,7 +155,7 @@ ct_main() {
# Pre-parse OPTIONS, a little ugly, but it works preparse() { - local args swap + local args tmpfs if ! ct_parse_options $OPTIONS; then error "Invalid options string: $OPTIONS" exit 1 @@ -392,7 +392,7 @@ ct_unmap() {
ct_map() {
- local name="$1" dev="$2" key="$3" args="" swap=0 + local name="$1" dev="$2" key="$3" args="" tmpfs local key_dev="" key_fstype="" key_mntpnt="" key_dev_umount=0 shift 3
@@ -401,7 +401,7 @@ ct_map() { return 1 fi
- # this function sets the args and swap variables + # this function sets the args and tmpfs variables if ! ct_parse_options "$@"; then error "Unable to parse options" return 1 @@ -520,13 +520,20 @@ ct_map() { ret=1 elif run cryptsetup create $key $args "$name" "$dev"; then info "sucessfully mapped '$dev' to '/dev/mapper/$name'" - if [ $swap -eq 1 ]; then + if [ "$tmpfs" = "swap" ]; then if run mkswap -f -L "$name" "/dev/mapper/$name"; then info "mkswap successful on '/dev/mapper/$name'" else error "mkswap failed for '/dev/mapper/$name'" ret=1 fi + elif [ "$tmpfs" ]; then + if run mkfs -t "$tmpfs" "/dev/mapper/$name"; then + info "mkfs successful on '/dev/mapper/$name'" + else + error "mkfs failed for '/dev/mapper/$name'" + ret=1 + fi fi else error "unable to map '$dev' to '/dev/maper/name/$name'" @@ -617,7 +624,7 @@ ct_parse_options() { case "$key" in swap) # set external variable - swap=1 + tmpfs="swap" ;; luks|plain) warn "Ignoring option $key, LUKS volumes are automatically detected" @@ -629,7 +636,9 @@ ct_parse_options() { warn "Ignoring Debian specific option '$key'" ;; tmp) - warn "The tmp= option is not supported" + # set an external variable + [ -z "$val" ] && msg "Defaulting tmp to ext4" + tmpfs="${val:-ext4}" ;; size) args="$args --key-size $val" -- 1.7.10.2
On 05/18/2012 05:15 PM, Tom Gundersen wrote:
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
wrote: It seems like some people use this. Use a new variable "tmpfs" to contain the file system type. Default to ext4 (Debian does this). Use the same variable to track the swap option too because we can only do one or the other.
For the record: I don't see the value of this, and think people should use a real tmpfs backed by encrypted swap.
That said, if there is demand for it I won't object. Does Debian support choosing your own filesystem or do they always use ext4? Having this be configurable seems a bit over the top to me...
I implemented this exactly as debian does, "tmp" means ext4, but "tmp=<anything>" works too. I have no use for it, and wasn't even planning to add it, but I saw how simple it would be following the mkswap support (which I and others definitely do use).
--- cryptmount.sh | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/cryptmount.sh b/cryptmount.sh index 37f5121..5320e3d 100755 --- a/cryptmount.sh +++ b/cryptmount.sh @@ -155,7 +155,7 @@ ct_main() {
# Pre-parse OPTIONS, a little ugly, but it works preparse() { - local args swap + local args tmpfs if ! ct_parse_options $OPTIONS; then error "Invalid options string: $OPTIONS" exit 1 @@ -392,7 +392,7 @@ ct_unmap() {
ct_map() {
- local name="$1" dev="$2" key="$3" args="" swap=0 + local name="$1" dev="$2" key="$3" args="" tmpfs local key_dev="" key_fstype="" key_mntpnt="" key_dev_umount=0 shift 3
@@ -401,7 +401,7 @@ ct_map() { return 1 fi
- # this function sets the args and swap variables + # this function sets the args and tmpfs variables if ! ct_parse_options "$@"; then error "Unable to parse options" return 1 @@ -520,13 +520,20 @@ ct_map() { ret=1 elif run cryptsetup create $key $args "$name" "$dev"; then info "sucessfully mapped '$dev' to '/dev/mapper/$name'" - if [ $swap -eq 1 ]; then + if [ "$tmpfs" = "swap" ]; then if run mkswap -f -L "$name" "/dev/mapper/$name"; then info "mkswap successful on '/dev/mapper/$name'" else error "mkswap failed for '/dev/mapper/$name'" ret=1 fi + elif [ "$tmpfs" ]; then + if run mkfs -t "$tmpfs" "/dev/mapper/$name"; then + info "mkfs successful on '/dev/mapper/$name'" + else + error "mkfs failed for '/dev/mapper/$name'" + ret=1 + fi fi else error "unable to map '$dev' to '/dev/maper/name/$name'" @@ -617,7 +624,7 @@ ct_parse_options() { case "$key" in swap) # set external variable - swap=1 + tmpfs="swap" ;; luks|plain) warn "Ignoring option $key, LUKS volumes are automatically detected" @@ -629,7 +636,9 @@ ct_parse_options() { warn "Ignoring Debian specific option '$key'" ;; tmp) - warn "The tmp= option is not supported" + # set an external variable + [ -z "$val" ] && msg "Defaulting tmp to ext4" + tmpfs="${val:-ext4}" ;; size) args="$args --key-size $val" -- 1.7.10.2
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
From: Matthew Monaco
The differences compared to the existing inline implementation are:
- can use cat again for loading - the calculated pool size can be local - quote file names... can't hurt
Looks good. We might end up moving to the systemd implementation of these things if Dave packages "systemd-tools" or something like that, but I'm happy to take this for the time being.
--- functions | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
diff --git a/functions b/functions index fd20349..b1dd5c1 100644 --- a/functions +++ b/functions @@ -506,6 +506,27 @@ bootlogd_stop() { -e 's/\^\[(\[1?[0-9][0-9]|%)G//g' -e 's/\^\[\[0;1//g' /var/log/boot }
+RANDOM_SEED=/var/lib/misc/random-seed +RANDOM_POOL_FILE=/proc/sys/kernel/random/poolsize + +load_random_seed() { + if [[ -f "$RANDOM_SEED" ]]; then + cat "$RANDOM_SEED" > /dev/urandom + fi +} + +store_random_seed() { + local pool_size + install -TDm 0600 /dev/null "$RANDOM_SEED" + if [[ -r "$RANDOM_POOL_FILE" ]]; then + read pool_size < "$RANDOM_POOL_FILE" + (( pool_size /= 8 )) + else + pool_size=512 + fi + dd if=/dev/urandom of="$RANDOM_SEED" count=1 bs=$pool_size &> /dev/null +} + ############################### # Custom hooks in initscripts # ############################### -- 1.7.10.2
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
From: Matthew Monaco
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
From: Matthew Monaco
We'll have the late hook in the initrd automatically map all volumes with an %early tag. Skipping them here is up for discussion though, as they should be skipped if they're mapped anyway.
I don't like this patch. Actually, not sure if I like the %early tag in the first place (is this the syntax other distro's use as well?). I don't think there is any need for marking things as %early, the only time the initrd might read the real crypttab is after the rootfs has been mounted, and then it's only job is to set up whatever is needed to mount /usr. Or am I missing some setup we want to support where the initrd can not figure out which volumes to map? Notice that encrypting /usr is almost entirely pointless, so we should be very hesitant to add syntax just to support this.
What should the procedure be if we're in rc.sysinit, and an %early volume is not mounted for whatever reason?
Then we should set it up.
rc.sysinit | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit index 270f384..be51dbb 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -153,7 +153,7 @@ activate_cryptos() { }
# Map any unmapped encrypted volumes in crypttab, non-random -activate_cryptos -O \!%random +activate_cryptos -O '!%early,!%random'
# Check filesystems run_hook sysinit_prefsck @@ -190,7 +190,7 @@ status "Initializing Random Seed" load_random_seed status "Storing new Random Seed" store_random_seed
# Map any unmapped encrypted volumes in crypttab, only random -activate_cryptos -O %random +activate_cryptos -O '!%early,%random'
status "Activating Swap" swapon -a
-- 1.7.10.2
On 05/18/2012 05:50 PM, Tom Gundersen wrote:
On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco
wrote: From: Matthew Monaco
We'll have the late hook in the initrd automatically map all volumes with an %early tag. Skipping them here is up for discussion though, as they should be skipped if they're mapped anyway.
I don't like this patch.
Actually, not sure if I like the %early tag in the first place (is this the syntax other distro's use as well?). I don't think there is any need for marking things as %early, the only time the initrd might read the real crypttab is after the rootfs has been mounted, and then it's only job is to set up whatever is needed to mount /usr. Or am I missing some setup we want to support where the initrd can not figure out which volumes to map? Notice that encrypting /usr is almost entirely pointless, so we should be very hesitant to add syntax just to support this.
I did this in response for two feature requests asking for more flexibility in the initrd. Without much code the %early tag allows for an arbitrary number of mounts. Others are not using tags like this, but sysd ignores unknown options so it should be safe.
On Sat, May 19, 2012 at 1:56 AM, Matthew Monaco
I did this in response for two feature requests asking for more flexibility in the initrd. Without much code the %early tag allows for an arbitrary number of mounts. Others are not using tags like this, but sysd ignores unknown options so it should be safe.
I'm hesitant to add new syntax without good usecases (as we have to support it for a long time). I think the correct way to do this is to map encrypted devices on-demand, but that doesn't really fit with the way we do things. I guess it would be ok to add the %early tags for now, and if people in the future add systemd to the initrd this stuff wolud "just work" with or without the %early tag, so it does not really matter what we do. -t
On 05/18/2012 06:28 PM, Tom Gundersen wrote:
On Sat, May 19, 2012 at 1:56 AM, Matthew Monaco
wrote: I did this in response for two feature requests asking for more flexibility in the initrd. Without much code the %early tag allows for an arbitrary number of mounts. Others are not using tags like this, but sysd ignores unknown options so it should be safe.
I'm hesitant to add new syntax without good usecases (as we have to support it for a long time). I think the correct way to do this is to map encrypted devices on-demand, but that doesn't really fit with the way we do things.
I guess it would be ok to add the %early tags for now, and if people in the future add systemd to the initrd this stuff wolud "just work" with or without the %early tag, so it does not really matter what we do.
-t
Don't forget, this is just an extension of my solution for random key devices. So if you don't like it we need to rethink it there. This was just a simple extension of that solution.
participants (2)
-
Matthew Monaco
-
Tom Gundersen