Excerpts from Mr Dash Four's message of Wed Oct 20 03:24:35 +0200 2010: > 1. 'dracut -I' option 'installs' the files specified, but does it > install all dependencies? For e.g. if I want to install > '/usr/bin/pkcs11-tool' does it install all other libraries/files on > which this program depends (i do not mean just .ko files!)? '-I' option are for user to include single files. If you'd like to merge files into initramfs with its dependencies, you use '*inst*' family functions. See 'dracut-functions' file. > 2. Currently the proposed rd_LUKS_KEYPATH and rd_LUKS_KEYDEV_UUID > allow me to specify key path and device to look for the key with which > to open the LUKS-encrypted drive/partition. If I want to open another > LUKS disk with a different key located in a different path/file how is > this handled? By specifying another pair of rd_LUKS_KEYDEV_UUID and > rd_LUKS_KEYPATH? First of all rd_LUKS_KEYDEV_UUID will be changed to 'rd.luks.keydev' and allow to specify devices by filename in /dev, LABEL or UUID. It's done a bit more flexible. You can specify 'rd_LUKS_KEYDEV_UUID' (later 'rd.luks.keydev') and 'rd_LUKS_KEYPATH' (later 'rd.luks.keypath') several times. For every 'rd.luks.keydev' ALL 'rd.luks'keypaths' are checked. I know that such approach have some flaws. I'll consider your proposition (quoted below) for specifying that. > 3. Following from 2 above: if smartcard module/enhancements are going > to be implemented then there is a possibility that there may be a > conflict (for example if I want to open drive A with keypath/file and > drive B with a token - how does dracut know which is which?). > > So, I have an idea: instead of using rd_LUKS_UUID, rd_LUKS_KEYDEV_UUID > & rd_LUKS_KEYPATH (and possibly also rd_LUKS_TOKEN for reading keys > from tokens) why can't we have one unified and much simpler format: > > a) for LUKS-encrypted drives (file/path keys): > rd.luks.<luks_uuid>=<keypath_uuid>:<fs>:<path> > > For example > rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=3de247f3-5de4-4a44-afc5-1fe179750cf7:ext3:/crypto/key_file > opens LUKS drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, using > key drive UUID 3de247f3-5de4-4a44-afc5-1fe179750cf7, mounting ext3 > file system and looking for file /crypto/key_file. > > b) for LUKS-encrypted drives (using token keys): > rd.luks.<luks_uuid>=<reader_id>:<slot_id>:<token_id>:<token_status> > > For example > rd.luks.def0269e-424b-4752-acf3-1077bf96ad2c=0:0:12:private opens LUKS > drive with UUID=def0269e-424b-4752-acf3-1077bf96ad2c, reading key > token using reader=0, slot=0 and looking for token data stored with > application_id=12, where: - reader_id: reader ID to use (not mandatory > - if omitted the 'default' reader is used); - slot_id: slot ID to look > for when reading the token (it could also be omitted in which case the > first available slot will be used); - token_id: the (application) ID > of the token as stored in the smartcard; - token_status: 'public' if > the token is stored in the smartcard as 'public' (i.e. no PIN login > required - similar to the key path scenario above); or 'private' if > the key token is stored as a private token and smartcard PIN is > required to read the token data; > > What do you think? rd.luks.key=<key_path>:<key_dev>:<luks_dev> Why this order? <key_path> is always required (obvious). <key_dev> doesn't have to be required, because it's easy to perform search for device (and it's done know, it works pretty well, at least with my latest not yet accepted patch which needs more improvement :-)). The last is optional too. Forcing user to write down all UUID-s is not ethical. ;-) It should be automated as far as it makes sense. Examples: rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc rd.luks.key=/some/file.key::UUID=00aabc rd.luks.key=/some/file.key:LABEL=cool_keys rd.luks.key=/some/file.key And probably I'll introduce this scheme in patches I'm improving recently. Does it satisfy you? :-) And for token it would be: rd.luks.token=â Might be? > My main concern is handling of all dependencies when installing the > core programs, which are going to do the 'dirty work': pkcs15-tool and > pkcs11-tool (possibly pkcs15-init also, though this program may have > to be used in extremely rare circumstances, if at all). 'inst*' functions family as I mentioned in previous e-mail. > I've looked through the dependencies and the package scripts though > there are, among other things, udev rules and config files, which > could complicate matters. Following this I have another query: Does > dracut have (at least read) access to the /boot partition where the > initramfs image is? No, no. You don't need access to /boot. You put everything in initramfs using installation functions provided by 'dracut-functions'. See 'install' and 'check' scripts in some module's directory. -- Amadeusz ÅoÅnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5
Attachment:
signature.asc
Description: PGP signature
