[AFS3-std] Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey Hutzelman wrote:

> I don't recall the conversation specifically, but there certainly is an
> established consensus that we should be adding get-capabilities ops to
> each interface.  Such an interface would return a bitmask of supported
> capabilities, similar to the ones we already have in some of the RPC
> interfaces.  Forgive me for not going back and looking at your patch to
> see if this is what you ended up defining.

What Marcus and I defined is, apparently, not a capabilities interface.
 Rather, it is a properties interface.  Rather than a bitmask, our
implementation is a dynamic string table.  The 'get' interface takes a
key, which may include wildcards, and may return values for multiple
keys.  In our code that uses this interface, we created the convention
of defining keys of the form <subsystem name>.<keyname>, so we have
'rxk5.enctypes'.  Although we did not initially implement a
corresponding set interface, we have been thinking that it could be
useful to have one, although we haven't (at least together) thought out
all the implications (ie, per-user vs. system-wide properties).  This
sort of interface would, I think, reduce the need for new get/set pioctl
interfaces for this that and the other.

> 
> Given that the number of supported token types is small, I don't see a
> problem with allocating a capability bit for each one; this is probably
> a better approach than using a separate pioctl.
> 
> Capabilities really don't address the lock thing, though.  The
> capabilities interface is intended to advertise what an interface
> provider is willing and/or able to support; they are read-only by
> nature.  They're also something that should behave consistently across
> implementations.  By contrast, the locking thing is really a
> configuration option for the OpenAFS cache manager; it needs both read
> and write, and is implementation specific.
> 
> So, I think we're talking about three pioctl's here:
> - get capabilities
> - get OpenAFS CM feature bits
> - set OpenAFS CM feature bits
> 
> The first belongs in the 'C' space, and there needs to be a registry for
> the capabilitiy bits themselves.  We're already doing this for some of
> the other interfaces, though the web pages don't yet exist for all of
> the registries.
> 
> I think the other two belong in 'O', since they really are specific to
> OpenAFS.
> 
> 
> I also think that neither of these interfaces covers the question of
> supported enctypes.  

Agreed.

> An aklog or equivalent program obtaining either
> rxk5 or rxgk tokens needs to know what enctypes are supported by the
> cache manager, in order to avoid getting a useless ticket.  My document
> on rxgk client integration indicates the need for such an interface but
> doesn't define one; I don't recall seeing one in your patch, either. 

It's there, although early versions of the patch didn't use it.  I think
we are now.

> You might argue that supported enctypes are capabilities, but I'd rather
> not treat them that way.  There is already an IANA registry of
> RFC3961/Kerberos enctypes, and I'd rather not have a requirement to
> designate a capability bit for every enctype before it can be used.
> 

We did not consider enctypes to be capability bits (see above), but
rather, we used an ascii representation of the integer number
corresponding to the enctype in the k5 specification.

> 
> 
>> As for pioctls, we'll happily send a request to
>> registrar@grand.central.org for the ones we actually require.  I would
>> ask, however, whether you really plan to issue an official pioctl, in
>> any range, for code that is unlikely to see wide or long-term use?  Is
>> it possible that there should be an X ('experimental') ioctl range for
>> this sort of work?
> 
> I allocated numbers for VIOCGETTOK2 and VIOCSETTOK2, but the details of
> these interfaces are still open for discussion.  I don't believe anyone
> has yet implemented the interfaces described on the afsig.se page, but
> if anyone has, they certainly know that they are subject to change.

Ok, thanks.

> I'll be happy to allocate a number for a get-capabilities bit, if you
> want to send a request in.  Feel free to CC me to get it quicker
> attention, as I don't wade through the spam there very often.  But I
> always ask that you actually send the request in to the registar
> address, because I use that queue as part of my recordkeeping.

Marcus or I will do this shortly.

> As for experimental use, the 'V' 240-247 codes are available for site
> specific use in both the ioctl and pioctl spaces; these should be usable
> for experimentation.  There is also an implementation-specific range at
> 'V'248-255, which may be appropriate for some experimentation (but be
> careful - OpenAFS doesn't use these codes, but other implementations
> might).

Ah.  Perfect.

> 
> The various lists of assigned codes can be found at
> <http://grand.central.org/numbers/>.  Be aware that they sometimes get
> stale, so don't assume a number is available just because it's not listed.
> 
> -- Jeff
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel




- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF245/JiSUUSaRdSURCACXAJ9WHfBioupwBqK2c1+IwMY6cl/R3gCdH2Gl
jl5OmloA+KT9h/zjr8bdYQ8=
=CNrJ
-----END PGP SIGNATURE-----