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

[Benjamin Kaduk]

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 sxw@EXAMPLE.ORG and sxw@HOME.ORG 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