Hello, I'm trying to figure out if I'm using the tools wrong, if I'm being protected from something, or if it's a missing feature. This came up because I want to normally have a password enabled, but when performing expected reboots, I can disable the password and avoid the 10 foot trek to the console.
Using FreeBSD 8.3, but a quick check of relevant HEAD code looks like it's the same. If I initialize a provider with "geli init -b -P -K keyfile provider", md.md_iterations defaults to -1. If I set a password later with "geli setkey -p -k keyfile -K keyfile provider", md.md_iterations is updated to a new useful value. When I then remove the password with "geli setkey -k keyfile -K keyfile -P provider", md.md_iterations is left as is, and can't be forced to -1. For attaching providers by hand, this isn't a big deal, but it is for the root filesystem. From what I've been able to uncover, g_eli_taste() checks for md.md_iterations=-1 indicate that there's no password to prompt for. This means I can't remove a password and still have a booting system because it prompts for a password, but a blank password isn't the same as no password. The documentation for "geli init -b" suggests that the BOOT flag is for prompting for a password, which does seem cleaner than having a magic value for md.md_iterations. That doesn't match how g_eli_taste() works, from what I can tell. Is it by design that md.md_iterations is not set to -1 after a password is cleared? I've thrown together a quick patch that resets iterations when the password is cleared on a provider that has a single key defined, and it seems to work. I can't help thinking I've missed something obvious here. Thanks, Ben -- Ben Korvemaker [email protected] _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "[email protected]"
