[OpenAFS-devel] New SetToken and GetToken pioctls

[Marcus Watts]

Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
> With the rise of new security mechanisms, the old Get and Set Token =
> pioctls are no longer capable of handling all of the various key =
> material that we need to shift between userspace and the kernel. A =
> proposal to remedy this was originally on the (now defunct) AFSIG wiki, =
> and some of what is below is built from the discussions there. Since =
...
> Any comments?
...

Have you cleared your name changes with the Arla folks?  pioctl_set_token
specifically comes from Love (should you give him credit?)
Gratuituous name changes don't simplify rxk5 integration.

For rxk5, it was specifically intended that the kernel understand
all tokens given to it.  The ability to set tokens the kernel does
not understand opens the "kernel credentials cache" discussion (which
you might not want), not to mention the difficulty of fixing problems
in that which does not complain.  In rxk5, there is also a separate
mechanism whereby aklog & friends can determine what token types will
be acceptable to the kernel.  What *was* intended was that *userland*
clients getting tokens out of the kernel might not understand all of
what's there.  The intent is that tools such as "unlog" or "tokens"
can do something reasonable in such cases.

jhutz mentioned the evils of AFSTOKEN_EX_SETPAG, and I quite agree that
it's most evil.  In rxk5 this was included only to ensure anyone
depending on this feature did not have any excuse to use the old
interface (and hence perpetuate its existance.)  Reserving a bit
for the behavior is different than requiring the behavior be present.
Given the feature hasn't gone away already, I would not predicate
the adoption of a new interface on this feature's disappearance.
Instead, I'd document this as a deprecated feature, which might
in the future only be implemented on certain platforms or releases.
If the feature is not implemented, the cache manager should reject
that set of tokens.  The feature should always be implemented if the
legacy interface is present and also includes that feature.

You've added the manifest AFSTOKEN_EX_ADD
I think that's not necessary.  A client that intended to do that could do
a "get token", merge its new thing in or make other changes, then do a
"set token".  I don't know why any client would be doing that though.
Sadly, my work has given me new vocabulary to ask that:
Can you present a "use case" for this?

				-Marcus Watts