>Whoa. I hadn't realized that they had done this stuff in assembly. I realize
>that the stuff in the kernel probably needs to have some assembly, but they
>really shouldn't have needed to go to assembly for the stuff in the user-level
>libraries/binaries. If what you say is true, it is very unfortunate because
>it means even those with a source license will find it hard to build shared
>libraries.
None of the kernel stuff is in assembler (that I know of). In defense of
Transarc (CMU, really), at the time it was the only way of reasonably
implementing a reasonably-portable threading library.
If you _do_ have a source license, you should definately spend some time
browsing the sources. It is quite an adventure :-)
Of course, I don't know all of the requirements of PAM modules, but if
you can exec(2) another program, you could just write something very
simple that just runs another program that does all the magic needed.
This would eliminate the need for having AFS shared libraries.
>Another alternative to consider is the use of a Kerberos gateway. I've not
>played with the K4 or K5 stuff, but I'd guess that there's a shared
>implementation of both of these, which could be tweaked to speak to the
>AFS kaserver. Not sure how you'd solve PAGs, though, since I can't seem to
>find any description of *exactly* how this works (other than that it consumes
>two group entries in the process group array.) I couldn't find any API calls
>to manage PAGs, either (and I'd appreciate hearing from anyone who has more
>specific information).
The AFS kaserver will pretend to be a K4 server, so you could write a K4
PAM module that just got a service ticket for AFS. You'd still need to
install the AFS token into the kernel, though. Also, I don't know if any
of the K4 stuff is available as shared libraries. The K5 stuff definately
are shared libraries already on some architectures, so presumably this
would be easier.
As for PAGs, there is some hope. The basic interface for creating a PAG
is setpag(); that's pretty much all you can do with PAGs. However, a
little-known fact is that there is a fourth argument to the ktc_SetToken()
library call. If this fourth argument is a "1", then a new PAG will be
allocated for the current process and and all processes in the current
process group. In other words, this is a way for a child to put it's
parent into a new PAG. So you could use this for a PAM module that
called another process to do the AFS magic. This is a bit tricky, however,
since I'm not sure what the rules are for the magical "ktc_SetToken()"
setpag(). The vanilla setpag() only affects the current process and future
children.
Unfortunately, to call setpag(), you need to link in RX, LWP, and a whole
bunch of other stuff. This is because setpag() can use rmtsys when you're
using a AFS/NFS translator (why, I have no idea, because PAGs certainly
don't work with the translator). If you want a lightweight setpag(), you
can use lsetpag().
And if you don't want to use _any_ Transarc library code at all, you can
track down lsetpag() and find out what it's doing behind the scenes. On
most architectures, you end up calling:
syscall(AFS_SETPAG)
or
syscall(AFS_SYSCALL, AFSCALL_SETPAG)
(The values of AFS_SETPAG, AFS_SYSCALL, and AFSCALL_SETPAG are port-dependent,
of course).
This the real magic that needs to happen. This would be easy enough to
put in a PAM shared library.
--Ken
