[arch-projects] [RFC 13/23] Check device with blkid before cryptsetup create

[Matthew Monaco]

On 05/18/2012 05:03 PM, Tom Gundersen wrote:
> On Fri, May 18, 2012 at 6:22 PM, Matthew Monaco <dgbaley27 at 0x01b.net> 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
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20120518/ab66dd55/attachment-0001.asc>