[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