[OpenAFS-devel] [FOR TESTING] pam_krb5 RPMs for RHEL4 that work properly (i386, x86_64)

[Christopher Allen Wing]

Harald:


On Mon, 9 May 2005, Harald Barth wrote:

>
> > I finally got around to doing a proper fix for these issues.
>
> Nice :-)
>
> > 1. pam_krb5 was basically doing 'fs whichcell /afs' to determine the name
> > of the local cell. So if you had dynroot enabled it wanted to obtain
> > tokens in a cell named 'dynroot'. I changed it to do the equivalent of 'fs
> > wscell' instead.
>
> Yes.
>
> > 2. pam_krb5 only tries to get tokens for the local cell by default. I
> > changed it to also try to get tokens in the cell containing the user's
> > home directory, if different than the local cell.
>
> Are you looking at TheseCells in configdir and $HOME/.TheseCells?

No. I just changed it to do the equivalent of:

	fs whichcell $HOME
	(get a token for that cell if != wscell)


TheseCells could be used; however, the same thing could be accomplished by
just doing an aklog in shell startup scripts, etc.

> > 3. pam_krb5 needs to know which Kerberos realm to use to obtain the
> > AFS service ticket. It basically uses the following procedure:
> >
> > 	fs whereis /afs/cell.name
> >
> > 	look up the DNS names of the file servers for /afs/cell.name
> >
> > 	use krb5_get_host_realm() on these DNS names to get the matching
> > 	Kerberos realm
>
> That is tricky but I doubt if this is the right strategy. What if your
> root.cell is in 2 different realms? (openafs.org was like that for a
> while) I think you have to go with the local realm of the workstation
> (DNS or krb5.conf) and if there is neither afs@WSREALM nor
> afs/cell@WSREALM I think you may as well give up. You may want to try
> afs/cell@CELL as a last way out.

I didn't write pam_krb5, and I'm not sure if I agree with this strategy
either. (One thing I don't like is that it relies on waiting for a
response from DNS to get the server's domain name; the other thing I don't
like is having to configure krb5_get_host_realm()'s mapping strategy by
hand)

My personal preference would be to always try afs/cell@CELL, and
afs/cell@WSREALM, with the ability to override this in a configuration
file (for cell names with non-matching realm names), and perhaps then fall
back to trying the old way with DNS and krb5_get_host_realm().

>
> > 4. Not all of the debugging statements in pam_krb5 were active, even when
> > 'debug' was specified in the pam configuration files. Some of the
> > debugging statements that didn't work were instrumental in figuring out
> > what was wrong with the above problems.
>
> Good. I never succeded in debugging PAM myself before.
>
> > 5. I also packaged the 'afs5log' program. This is included with the source
> > code of pam_krb5, and basically does the same thing as 'aklog', except
> > using Red Hat's own AFS code instead of the actual AFS libraries.
> > It's useful for debugging purposes since it acts mostly identically to
> > pam_krb5.
>
> Ah.


I assume that these RPMs will mainly be useful to people trying to run
OpenAFS on Red Hat systems, which is what I am trying to do.


Thanks,

Chris
wingc@engin.umich.edu