On Fri, 17 May 2013, Simon Wilkinson wrote:
On 17 May 2013, at 04:23, Benjamin Kaduk wrote:
Looking at the old proposal from
http://web.archive.org/web/20061009074046/http://www.afsig.se/afsig/space/prdb+extensions
Thanks for rediscovering this.
Brandon Allbery found it, actually.
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.
You need to support multiple authentication names for a single pts entry
- mapping [email protected] and [email protected] to the same pts entry is a
perfectly valid use case.
Okay, that's sufficiently compelling that I'll drop it. (You could just
use a group, but that seems a bit silly).
However, I don't think that you need to overload the hash tables for
this purpose. By my reading of this specification (I haven't implemented
this), you have a single extended hash table which hashes the exported
name portion of the authentication name to an authentry. The authentry
then contains a pointer to the pts id with this extended authentication
name. It also allows multiple authentries to be chained together when
the exported name is longer than 160 characters.
Agreed. (I also convinced myself that the naive way wouldn't work,
anyway.) This is probably the better of the two options I had in mind --
we could go to a tree structure, but I fear that such an endeavor would be
rushed and under-analyzed.
To go from pts id to authentication name, you use the authnames field
(the spec has this as 'reserved0') of the prentry record for that id.
This links you to the first authentry record. If the id has more than
one authentication name, then the authName pointer of the first
authentry chains you into the second, and so on.
Right.
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?
I think this is correct.
Yay
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.
I don't have a strong preference one way or another. I think at some
point we're going to need to rework the record format anyway, so using
up the last reserved pointer doesn't worry as much as it usually would.
I agree that a full PRDBVERSION bump is in the wings, so I personally
would not worry too much about using the last reserved field.
jhutz seemed to feel otherwise, though, advocating a more general
extension framework.
I think the specification you have found is actually pretty complete. My
only concerns would be with three areas that you haven't addressed.
Firstly, storing X500 based authentication names is likely to rapidly
exhaust the available 32 bit address space (it takes 192 bytes of record
to store 160 bytes of data, and some X500 names can be huge). Secondly,
Sure, but I don't think we're going to be able to shoehorn a solution to
that problem into the existing format/framework. I fear that reasonable
treatment of x500 names is going to end up waiting for a full revision of
the prdb format.
there's no provision for storing display names for the extended names.
This means that a ptserver may end up holding extended authentication
names that it can't produce a printable representation for. Thirdly, the
I can think about this some more. Off the top of my head, it's probably
okay to use the krb4 name (if present) as a display name, and we could
hack a display name into the space that would otherwise be used for the
krb4 name if no display name was present.
hash to be used to for the authentication name hash table isn't
specified.
Reusing the old NameHash is probably not a good choice. I'll think about
think about this, too.
Thanks,
Ben
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
