[OpenAFS-devel] bos superusers and pts extended names

Benjamin Kaduk kaduk@MIT.EDU
Wed, 8 May 2013 15:29:30 -0400 (EDT)


draft-brashear-afs3-pts-extended-names-09.txt (which despite the name is 
an experimental standard, up at http://afs3-stds.central.org/) specifies 
handling for GSS (and krb5) names.  It makes the distinction between a 
"display name" and a "data name"; the former is supposed to be a printable 
string and the latter is not necessarily printable.  All comparisons for 
authentication purposes MUST use the opaque ("data") form of the name.

As such, the UserList configuration file for bos is no longer sufficient, 
as it is not compatible with possibly-binary data.  In keeping with the 
use of a KeyFileExt file to store non-des key data, I propose adding a 
UserListExt file to hold non-krb4 name types (as will be needed for rxgk).

I'll describe my proposal for the format of this file in words; if that is 
unclear, I can prepare ASCII art for the bit positions.

The file consists of an initial header, followed by entries.
The file-wide header has a 32-bit version number field, for the version of 
the UserListExt file format in use.  This version would start at 1 and 
only change if backwards-incompatible changes are needed.  The only other 
entry in the file-wide header is the number of name entries in the file.

Each entry starts with 32 bits of magic (a to-be-determined constant bit 
string) to help detect file corruption, followed by 32 bits with the 
length of the per-entry metadata (including magic), 32 bits for the type 
of the name (the "PRAUTHTYPE_" constant), 32 bits for the length of the 
name material, and then the actual data name itself.  Entries are not 
necessarily word-aligned; they follow right after the end of the previous 
entry.

Does this seem like a reasonable plan?  In looking at the KeyFileExt 
format, it seems that the "metadata length" field can help somewhat with 
detecting inconsistences; perhaps with such a field the "magic" field is 
not necessary.

-Ben