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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
