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