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

[Douglas E. Engert]

Russ Allbery wrote:
> 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.

So does gafstoken. it builds a apagaix.a file with the lsetpag() call,
and gafstoken.c dynamic tries to load this.

> 
> 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. 

But yes I do worry about this, as we have installed MIT Kerberos code
which called the gafstoken on systems without AFS. In this case gafstoken
catches signals for missing syscalls, or on AIX returns if it can
not load the apagaix.a

  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.
> 

I have not tried the gafstoken on AIX 5, as the last AIX we had was 4.2
where the same code as in gafstoken worked.

> 
>>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.
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444