[OpenAFS-devel] prdb format extension for extended authentication names

[Benjamin Kaduk]

Looking at the old proposal from 
http://web.archive.org/web/20061009074046/http://www.afsig.se/afsig/space/prdb+extensions 
and thinking about the current structure of the prdb (I wrote up some 
notes at https://github.com/kaduk/openafs/blob/prdb/doc/txt/prdb.txt), it 
seems clear that we will need a new entry type/structure to hold the 
actual (potentially binary) data for extended authentication names, and 
that an additional hash table (or other data structure) will be needed to 
provide a reasonably efficient entry lookup by extended name.  For 
consistency with the existing format, it's probably best to stick with a 
hash table for now.  There are a lot of things that could be done with a 
PRDBVERSION bump, but that seems like a larger project than is needed to 
get working rxgk support.

The old proposal has an approach for assigning additional hash tables, 
which is general enough to allow multiple new hash tables to be added. 
This may be needed, because the extended authentication names document 
provides only a way to add an authentication name to an existing prdb 
entry, but does not appear to prohibit doing so multiple times.  That is, 
a given prdb entry could in principle have multiple extended names 
associated with it.  This is bad from a prdb format perspective, because 
each prdb entry can only appear once in a given hash table (given a fixed 
link field per hash table), and different names for the same entry will 
likely have different hash values.  The naive approach would require as 
many (new) hash tables as a single entry has extended names; this would 
suggest that we limit entries to only one extended name (of a given type, 
I suppose, though GSS names are the only new name type, given that krb4 
names are retconned into the existing name field).  If imposing a limit of 
one GSS name per user is not acceptable, we will need to get more creative 
(I have at least two potential ideas) -- is such a limit acceptable to us?

Another issue is whether extended names should be limited to user entries. 
It seems clear that the intent is that only user entries can be directly 
authenticated to, but I believe it is possible at present to authenticate 
to a group entry "by accident", i.e., if the name happens to line up 
right.  I am happy to enforce that only user entries can have associated 
extended names; does anyone feel otherwise?

Given my feeling that only user entries should get extended names, there 
are actually quite a number of fields that are available for this use: 
nextOwner is only used for group entries, and supergroups have claimed 
instance, parent, sibling, and child for their use -- which is *also* only 
for group entries.  So user entries have some five fields potentially 
available in addition to the explicit reserved field.  Extended names 
could in principle be added while leaving the explicit reserved field free 
for a generic record extension structure.

If there is consensus on the general structure/general questions, I can 
prepare a more detailed proposal for discussion.

To summarize, the interesting questions posed are: hash table for extended 
names, limit of one extended name per entry, and limit extended names to 
user entries only.

Thanks,

Ben