[OpenAFS-devel] Simplified integration of OpenAFS, Kerberos SSH and PAM (again)

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:
> Russ Allbery wrote:

>> Right, yeah.  It's a very simple function in most (possibly all) cases.

> AIX was messy, but I have not looked at AIX in a few years.

AIX is messy because AIX would (used to?) refuse to run a binary that
contained system calls that the local system didn't understand, even if
those system calls were never actually called.  As a result, the KTH
Kerberos code first checks to see if AFS is in the kernel, and then, if it
is, loads a dynamic library that contains the actual system calls.

If you don't care about the code running on a system that doesn't have AFS
in the kernel, you don't have to worry about that stuff.  It may also be
that AIX 5 doesn't have this behavior; I've not looked at AIX 5 at all.

AIX support is something that I think I'd rather leave to people who
really care about AIX.  My recommendation would be to bail on anything
prior to AIX 5.3, since the whole LAM thing is just more trouble than it's
worth.

> OK, the same lib could have the setpag routine and ktc_setToken like
> routine as Jeff points out as long as it does not require any extra
> libs.

I've now taken an extensive look at this and have started playing with
code.

It turns out that the library that I was thinking of already exists, and I
just wasn't familiar enough with the AFS code to know about it.  It's
libsys.a.  This contains only the system call layer and the necessary glue
to talk to the kernel, without any elaborations.  This is even lower level
than ktc_SetToken; this is pioctl.

Now, I see two ways going forward.  pioctl is as low-level as you get, but
it's really not particularly useful without the wrappers that AFS puts
around it.  It doesn't seem particularly likely to me that a lot of code
outside the AFS source tree is ever going to be calling pioctl directly,
nor would I want to maintain such stuff.  So one route is to bail on
worrying about ktc_SetToken right now, as you were trying to convince me,
and just build a library that contains setpag (or, actually, lsetpag, as I
have no desire to deal with the AFS/NFS translator in this context since
it immediately hauls in RX and then away we go into dependency hell
again).

The other route is to basically provide a shared libsys, probably as
libafssys, including all the stuff in libsys.  That means the inode calls
as well as setpag and pioctl, and possibly the debugging stuff; I haven't
bothered to figure out if that's live code.

I'm currently leaning towards (and implementing) the former option, but if
someone wants to talk me into the latter option, let me know.  I think
setpag is sufficiently special that having a shared library containing
only it is worth doing.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>