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

[Simon Wilkinson]

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.

> 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.

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.

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.

> 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.

> 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 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, =
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 =
hash to be used to for the authentication name hash table isn't =
specified.

Cheers,

Simon