On 05/08/2013 03:29 PM, Benjamin Kaduk wrote:
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.
How would you manage the list of admins using a configuration system,
like puppet? Would you have to use to "bos adduser"?
Jason
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
