GELI file systems unusable after "glabel label" operations

[Roland Smith]

On Fri, Jan 22, 2010 at 03:08:00AM -0600, Scott Bennett wrote:
>
>      Why is that stored in the last sector of the device, rather than in the
> key file?  What is the purpose of the key file if not to hold that type of
> information?

All geom(4) providers use their last sector to store metadata; it's a design
decision. Probably because the first sector(s) are used for boot blocks or
filesystem metadata etc.

It would have been possible to store the generated key in the user-provided
keyfile. But since it is not mandatory to have a keyfile (you can also use
just a passphrase), it makes more sense to use the already provided metadata
space in the last sector.

> >Well, it should be different, otherwise they overwrite the same sector. Ipso
> >facto you should nest providers...
> 
>      ...unless, of course, the two had been designed to use different parts
> of the "last sector" for their own purposes, but also to avoid damaging the
> other's data when altering their own.

The geom framework was designed to be _extensible_. It was designed so that it
would be possible to combine (nest) different types of geom providers, even if
those classes (types of providers) didn't even exist when the framework was
designed. Trying to shoehorn all metadata for any combination of geom
providers into on 512-byte sector would have severely limited the usability of
the geom system.

In my opinion the solition of using nested providers each using their own last
sector for metadata is simple and elegant and avoids that problem rather nicely. 
As I've been trying to explain, the 'nesting' of geoms is _precisely_ what
avoids the whole issue of damaging each others data.

I've got the feeling that you do not 'get' that concept, which lead to your problem.
Unfortunately, I don't know how to explain it more clearly. 

>      Thanks for the explanation.  However, if the key information is stored
> in the "last sector" rather than in the key file, then I guess I'm totally
> confused about how GELI works.

The encryption key is _not_ stored in the last sector. That would be unsafe,
like locking your front door and leaving the key in the lock. But a part of the
information necessary to create the encryption key is.

Your keyfile is just one component of the en- / decryption key to unlock the
data. They are not the same. You can use one or more keyfile(s), a passphrase
or both. You can also have more than one key; a user key and a 'company' or
system key. And geli uses a random component when the encryption key is
initially created. The metadata sector is the natural place to store some of
that info. This is safe because it is in itself not sufficient to create the
en- / decryption key. One also need the keyfile and/or passphase.

Personally, I would never use only a keyfile; it is not really secure,
especially if you leave that key on another unencrypted partition of the same drive!
So-called two-factor authentication (something you have [keyfile] and
something you know [passphrase]) is much safer.

If you really want to know how geli works, as always with free software, the
source code is the ultimate reference. :-)

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100123/3036d06c/attachment.pgp