[OpenAFS] home on afs woes

Douglas E. Engert deengert@anl.gov
Thu, 12 Jan 2006 14:05:08 -0600


Juha J=E4ykk=E4 wrote:


>=20
> Suggestions?
>=20
> I have one: there is such a thing as pam_afs2.so, which I found somewhe=
re,
> which can run arbitrary programs as part of PAM login process (at auth
> stage, if I recall). It can do afslog (and it even comes with its own
> afs5log of which I know nothing) instead of aklog if I wish, but I don'=
t
> know if it does PAG at all.

The pam_afs2 is mine. It can get a PAG from any of the pam_sm_* entry poi=
nts.
It does not have its own afs5log.

It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE

pam_afs2-0.1.tar
    The pam module that will get a PAG using a syscall, then fork/exec
    some program to get a token. It passes the pam_env to the program and
    runs it as the user. The exec'ed program could be the OpenAFS aklog,
    or the Heimdal afslog for example. (We have something local called ak=
5log,
    that was around since DCE days that used K5 protocols as much as poss=
ible.)
    We also have the gssklog, see below.

gafstoken-0.3.tar
    The shared lib called by the pam_afs2 that has the syscall to get the=
 PAG,
    and the code to do the fork/exec (It compiles and links with out any =
AFS
    or Kerberos headers or  libs.) It does have some knowledge of what sy=
scall
    to use on what system.) On machines with the MIT daemons like ftp, kl=
ogin,
    kshd a local mod uses this as well.

gssklog-0.11.tar
    This is an alternative to aklog, that uses gssapi to authenticate to
    one of the gssklogd daemons running on the afs database servers. It t=
hen
    returns a token protected by the gss_wrap. It use the same set of par=
ameters
    as aklog, so can be forked/exce'ed by the gafstoken called from the p=
am_afs2.


The design goals of all of this was to keep AFS as far away from Kerberos
as possible, and never have to rely on a vendor's daemon to have to link
(even dynamically via pam) with either and especially with both.

The gssapi used in gssklog does not even have to be Kerberos! It was orig=
inally
designed for use with the Globus GSI gssapi. (But that is another story.)

For example on Solaris 10, we are using the Solaris sshd, Solaris Kerbero=
s,
and Solaris pam_krb5. The pam_afs2 gets called, with the KRB5CCNAME set,
and this gets passed during the fork/exec of the gssklog that is using th=
e Solaris
gssapi. I even got the OpenAFS aklog to link and run with the Solaris Ker=
beros.
and can use that instead of the gssklog. ( There is no MIT or Heimdal Ker=
beros
on these machines, other then what the AFS kernel has built in.)


>=20
> Cheers,
> Juha
>=20

--=20

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