Bug 193302 - modifiy /etc/rc.d/geli to handle multiple providers with the same password/keyfile
Summary: modifiy /etc/rc.d/geli to handle multiple providers with the same password/ke...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-rc (Nobody)
Keywords: patch
Depends on:
Reported: 2014-09-04 03:07 UTC by karl
Modified: 2017-04-23 18:58 UTC (History)
1 user (show)

See Also:

addition to /usr/local/etc/rc.d (3.21 KB, text/plain)
2014-09-04 03:07 UTC, karl
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description karl 2014-09-04 03:07:14 UTC
Created attachment 146761 [details]
addition to /usr/local/etc/rc.d

A common configuration with ZFS filesystems (in particular) contains many volumes that are then aggregated into a pool, with ZFS filesystems associated.  This leads to a requirement to type a password (if one is used) many times (potentially a dozen or more!) on a boot, as the geli script makes no attempt to get the password itself, but relies on the /sbin/geli code itself.

If the providers all have the same password and keyfile (or just a password) then it would be much nicer to have to enter the password only once during system boot time, or at most twice (if root is also encrypted.)

This modification of the "geli" script, named "encrypt" and placed in /usr/local/etc/rc.d, replaces the "geli" script and permits this -- it accepts the same options (for the most part) as geli does, except for the detach parameter which is not supported, asks for the password itself and then iterates over all the providers given and attempts to attach them sequentially.  I modified and renamed the existing script rather than simply proposing a patch for the instance where you may want to support both the previous (one prompt per provider) and this (one prompt for a group of providers) paradigm on the same system.
Comment 1 karl 2014-09-04 20:28:19 UTC
This has to go into /etc/rc.d, not /usr/local/etc/rc.d, in order to be run in time before the zfs mount happens.

That may mean the right thing to do is refactor the geli script instead..... 

Anyone have comments and thoughts?
Comment 2 Christian Brueffer freebsd_committer 2015-07-02 12:00:42 UTC
An in-kernel geli password caching feature was implemented in r271664 and merge to 10-STABLE in r272006.  It sounds like an alternative solution to what you propose here.  Could you give it a try and see if it solves your problem?