On 16 Feb 2010, at 19:56, Marcus Watts wrote:
Simon Wilkinson <[email protected]> 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?)
Name changes don't affect the wire protocol. I've been careful to
leave types, and field positions intact. Where I have changed names,
it's been in the interests of clarity, and avoiding conflicts with
other existing structures.
I've actually received feedback suggesting that the current
ktc_setTokenData should be renamed (because it's used for both Get and
Set), so I'll probably end up calling that ktc_tokenData.
Gratuituous name changes don't simplify rxk5 integration.
I doubt rxk5 will have anything to do with the names used in the XDR -
it won't be the sole consumer of the new Set and Get pioctls, after
all. The current implementation adds the concept of a 'tokenJar' to
the kernel module - each PAG has one of these. The new pioctl
operations manipulate these jars, and interface functions are provided
to allow security classes to pull usable tokens out of the jar. This
abstracts out the storage requirements of particular classes from the
unixuser structure, and should help the code from becoming overrun
with #ifdefs.
I'm hoping that the work I'm doing on cleaning up the security class
interfaces throughout the AFS code should actually make it easier for
both rxgk, and rxk5 to drop in. There have been a lot of changes
recently (look for commits from [email protected]) aimed at
carving out the necessary hooks - the way clients and servers allocate
security layers has been changed, aklog has been radically
restructured to permit easier addition of other token types, the afs
pioctl code has been reworked, a new kernel token cache implementation
has been produced, and so on. I suspect these won't simplify the task
of porting rxk5 forwards, but they will hopefully mean the amount of
code you have to merge is significantly less.
For rxk5, it was specifically intended that the kernel understand
all tokens given to it.
The intention of the token jar is that it will store tokens for all.
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.
Many of our tools currently rely on retrieving tokens from the kernel
in order to perform operations. This is the path of least surprise for
our users, and is one I'm keen to continue to support. We have to
permit version skew, where it's possible that userspace support one
set of RX security classes, and the kernel support a different set.
So, userspace needs to be able to set, and retrieve, tokens that the
kernel doesn't understand. We also need to be able to support the
kernel and userspace security layers having different feature sets.
For this reason, multiple tokens for a single security mechanism may
be added, some of which will be usable by the kernel, and others
usable by userspace.
In rxk5, there is also a separate
mechanism whereby aklog & friends can determine what token types will
be acceptable to the kernel.
Sure - userspace needs to have a way of negotiating tokens which are
going to be usable by the kernel. But it also needs a way of storing
tokens for its own use.
jhutz mentioned the evils of AFSTOKEN_EX_SETPAG, and I quite agree
that
it's most evil.
All of the feedback I've received so far has advocated dropping this
from the new pioctl. However, I'm very aware that this is developers
talking. I'd be interested in feedback from users too, and I'll
shortly send an email to the info list about this one topic.
Cheers,
Simon
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
