[OpenAFS] home on afs woes

Douglas E. Engert deengert@anl.gov
Thu, 12 Jan 2006 09:10:11 -0600


Russ Allbery wrote:
> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> 
> 
>>No it doesn't.  All it needs is a relatively simple library which
>>provides a way to check for the presence of AFS and to make AFS system
>>calls, particularly setpag and pioctl.
> 
> 
>>Conveniently, heimdal comes with such a library; it's called libkafs and
>>includes functions like k_hasafs(), k_pioctl(), k_unlog(), and
>>k_setpag().  IIRC, Derrick used to distribute a standalone version of
>>this library for people not using Heimdal, but it's probably pretty
>>stale by now.
> 
> 
> Certainly such a library would be useful.  If someone wants to implement
> it without all of the dependencies that Heimdal libkafs has, I'd be all in
> favor of it.  Heimdal's libkafs has significant dependencies and isn't
> really suitable for use outside of a system built with Heimdal in general.
> 
> 
>>Ugh.  lsetpag() is not really intended to be a public interface.  The
>>public interface provided by AFS is called setpag().
> 
> 
> Providing setpag in a shared library that's actually maintainable is,
> right now, unfeasible in OpenAFS without a great deal of work.  If you
> don't agree, please do say so, but I looked at it somewhat seriously and
> it was way more work that I thought was likely to happen.  It requires,
> for instance, pulling in all of Rx.
> 

I agree, setpag has too much baggage added for the translator I believe.
lsetpag is basiclly a syscall.


> Doing that work requires caring way more about the NFS translator than I
> do, I'm afraid.
> 
> 
>>Also, I'd suggest that instead of a shared library containing only
>>lsetpag, it might be better to provide a library containing the
>>functions I named above, with the same API that the KTH folks have been
>>distributing for years.
>
> 
> I think it would be better, yes, but it's a lot more work if you want to
> really match APIs, since that requires providing krb_afslog and
> krb5_afslog.
>

Setting of the PAG has little to do with Kerberos, and no Kerberos
code is need to set the PAG. The idea is to get the PAG at the daemon
process, then later on in other processes or even in the same process add tokens
under the PAG.


> Basically, we'd be talking about taking most of aklog and putting it in a
> library.   Which isn't at all a bad idea, but it's a larger project, and
> I'd really like to see a solution for this in the shorter term.  Long
> term, absolutely, I think that's a fine idea, and if we can keep it
> API-compatible with Heimdal, that would be awesome.

Yes, aklog in a library, fine, but keep the setting of the PAG separate.
Ideally, you would like the setting of the PAG to be so trivial, that
any vendor would always add this into all of their daemons, even if
AFS was not present.

If you want something short term, see the gafstoken which is used
by pam_afs2. It traps SIGSYS and SIGSEGV, then does a syscall,
on linux, tries the open(PROC_SYSCALL_FNAME, O_RDWR); and
open(PROC_SYSCALL_ARLA_FNAME, O_RDWR); first, then tries a syscall.


> 

-- 

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