FS#11648 - [initscripts] removable device option for /etc/crypttab

Attached to Project: Arch Linux
Opened by Thomas Lingefelt (procdaemon) - Friday, 03 October 2008, 15:50 GMT
Last edited by Andrea Scarpino (BaSh) - Thursday, 09 December 2010, 08:01 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity Very Low
Priority Normal
Reported Version 1.5.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I hope this isn't a duplicate. I would very much like to see support for decrypting with passfiles located on removable devices. This feature is already available in the initrd encrypt hook, and would like to see it in the system init script.

Therefore I am submitting a patch for /etc/rc.sysinit (SHA1: 0762e263a155d641979ccef98d15c34eecfc2fdf) to add this. I've been using it for about a two weeks with no adverse effects.

This code will add another PASSWORD option format to /etc/crypttab. The new option will be in the form /path/to/device:/path/to/passphrase . Much like the initrd crypt hook, if /path/to/device does not exist it falls back to asking for a passphrase.

Here's an example of my own personal crypttab entry...
crypt-thomasl /dev/mapper/picard-thomasl /dev/disk/by-label/Keys:/picardthomaslkey

One thing I don't like about my patch is that the removable device is temporarily mounted in the /tmp directory instead of a sub-directory of /tmp. I did this because / is mounted read-only then the concerned code is run, and the decision to relocate the crypttab code after root is mounted read-write should be up to a dev. My solution probably isn't the best idea, so please review/improve this patch.

This task depends upon

Closed by  Andrea Scarpino (BaSh)
Thursday, 09 December 2010, 08:01 GMT
Reason for closing:  Implemented
Additional comments about closing:  http://projects.archlinux.org/initscript s.git/commit/?id=392990639656d14db854aaf 62d3a0a471c013111
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 07 June 2009, 21:31 GMT
This reports has many months.

@procdaemon: Is this still valid? Can you resubmit the patch with the proper format (unified)[#1] and against latest git version? This makes more easily to review. Thanks.

[#1] Clone the git repo, or simple use "diff -u".
Comment by Thomas Bächler (brain0) - Sunday, 07 June 2009, 21:42 GMT
Yes, this is not a bad idea, but I'd like to see a unified diff here.

Why was this bug never assigned before?
Comment by Thomas Lingefelt (procdaemon) - Wednesday, 10 June 2009, 21:22 GMT
OK I've cloned the GIT repo and produced a new diff (sorry my first patch wasn't the correct format).
I've been using essentially (with no changes to the code in question) the same script since October, and I've kept initscripts updated to the newest versions most of that time.
During normal usage I've still not detected any adverse effects.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 12 June 2009, 23:04 GMT
  • Field changed: Status (Waiting on Response → Assigned)
Thanks for the patch. Now devs can review this more easy.
Comment by Heiko Baums (cyberpatrol) - Thursday, 06 August 2009, 11:18 GMT
Thomas Bächler, may I also remind you on my feature request  FS#15016 ? It's not the same patch, but for reading the key as raw data from a removable device. ;-)
Comment by Aaron Griffin (phrakture) - Friday, 02 October 2009, 22:54 GMT
Thomas is kind of the king of cryto stuff, so I'll let him review this one.
Comment by Thomas Bächler (brain0) - Saturday, 03 October 2009, 11:15 GMT
Thanks for the patches, and I basically like it. However, adding more and more new syntax into an unflexible config file like crypttab will eventually make it too complex. I am redesigning crypto support for Arch initscripts now, so I can add more features without making the configuration and code completely awful. The new format is designed to be intuitive and feature-rich, so you'll get what you want soon.

http://mailman.archlinux.org/pipermail/arch-dev-public/2009-October/013728.html
Comment by Thomas Lingefelt (procdaemon) - Saturday, 03 October 2009, 12:22 GMT
Thank you. That's really good to hear.

Loading...