[OpenAFS-devel] OpenAFS and OpenSSH, PAM, tokens

[Douglas E. Engert]

Russ Allbery wrote:

> Douglas E Engert <deengert@anl.gov> writes:
> 
> 
>>If it was integrated into the source, I would expect to use the
>>lsetpag, and glue source and header files to be able to get a PAG.
> 
> 
> You can't use lsetpag in a PAM module right now.  There is no shared
> library that provides it.

I did not say shared lib, I said source. Could use the .o files instead
I would suspect.

>  I think the consensus was that this wasn't the
> PAG interface we really wanted to put more work into; the kafs interface
> is better.
> 

I am not talking a lot of work. It looks like it is all but done.
pam calls lsetpag() and links with sys/sepag.o and sys/glue.o

> 
>>I would rather avoid the kafs interface and use the external aklog if at
>>all possible. It avoids bringing in any additional AFS libs and their
>>dependencies into an application that calls PAM thus avoiding clashes
>>and keeping it simple.
> 
> 
> I believe the kafs interface is the correct long-term approach for most
> sites, and therefore want to work on a PAM module that uses it, but it
> will be an optional compile-time configuration on Linux at least since I
> need something that works on Linux with OpenAFS right now and libkopenafs
> is an OpenAFS 1.6 thing.  Once libkopenafs shows up, you'll have what you
> want for the time being since libkopenafs will be a stand-alone shared
> library that only exposes the k_hasafs, k_setpag, k_pioctl, and k_unlog
> interfaces; the PAM module built against libkopenafs (or on Linux without
> any supporting libraries) will not have any Kerberos dependencies and will
> always use an external aklog.
> 
> Eventually, I would like to see aklog become a library that provides the
> rest of the kafs interface, but when we do that, we can try to ensure that
> people who want to avoid Kerberos dependencies can continue to do so.
> Maybe rather than integrating those functions into libkopenafs, we'll add
> a new library or something.  That bridge is a bit off into the future,
> though, so we can worry about crossing it later.
> 

OK, I won't do much now, but will be waiting.


-- 

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