> > I would have thought pam_krb5.so [1] does this by itself, but
> It's only a PAM module for Kerberos.  It doesn't know anything about
> AFS.

I disagree. From its README:

o tokens
  Create a new AFS PAG and obtain AFS tokens during the authentication
phase.  By default, tokens are obtained for the local cell (and the cell
which  contains the user's home directory, if they're not the same).

Except that, like I said earlier, it seems to rather inherit the PAG from
its parent. Perhaps I need to investigate it further. Or perhaps it fails
to create the PAG when doing ssh/GSSAPI.

Anyway, apart from pam_unix.so, my PAM config has nothing but I still get
my AFS tokens at login, no matter how I authenticate (GSSAPI or Heimdal
passwords - using ssh/pubkey of course does not give me the tokens).

> libpam-openafs-session in Debian.  There are others floating around as
> well.

Which depends on aklog, which segfaults.

> AFS doesn't do AES, at all.  If you do have a DES key for AFS, I don't
> see why that aklog wouldn't work, but it's also fairly old.  Soon we'll

Well, I do and it does not. I suppose it does not like even the user
having an AES key.

> for putting your parent process in a PAG (and for right now
> libpam-openafs-session even relies on it), but it's not the default.

Is this again due to the differences between MIT and Heimdal that we need
to use an additional AFS module beside plain kerberos? Heimdal kinit does
everything I need, except the PAG. Or does it do the PAG too well?

These happen in an xterm:

~> kinit foo
[EMAIL PROTECTED]'s Password:
~> touch /afs/something/you/dont/have/write/permission/to
touch: cannot touch `<the path above>': Permission denied
~> xterm -e 'kinit foo/admin'
[type the password in the other xterm]
~> touch /afs/something/you/dont/have/write/permission/to
~> ls /afs/something/you/dont/have/write/permission/to
/afs/something/you/dont/have/write/permission/to
~> 

I.e. kinit replaced the token of the parent xterm. Actually, it replaces
all the tokens of all the processes in the same X session. If I have a ssh
session to localhost, its tokens remain unaltered but all processes
running under the same X get replaced. [I am a little imprecise here: I
only tested processes running as children of the same window manager, but
I suppose it makes no difference if I used the xsm to open a new xterm
instead of the wm.]

> > it's the old RedHat pam_krb5.so emerged with the sf.net version and
> > with still active development unlike any other pam_krb5.so I can find.
> The Red Hat Kerberos PAM module scares me.  The PAM module in Debian is
> under active development with a different upstream and handles some
> things better (and will handle quite a few more things better when I
> find time to get the next version uploaded).

Except that it does not work. =) Well, it works, but it really is just
kerberos, no AFS. It needs libpam-openafs-session to go with it and THAT
does not work. I'd go for Debian's pam_krb5 and pam_openafs_session any
time, if they worked.

I am all for "one program does on thing" ideology (i.e. pam_krb5.so does
kerberos and pam_openafs_session does afs instead of a monolithic
pam_krb5.so doing both), except that there seems to be no working
combination of these two for Heimdal 0.7.1 and user AES keys.

Suggestions?

I have one: there is such a thing as pam_afs2.so, which I found somewhere,
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.

Cheers,
Juha

-- 
                 -----------------------------------------------
                | Juha Jäykkä, [EMAIL PROTECTED]                        |
                | Laboratory of Theoretical Physics             |
                | Department of Physics, University of Turku    |
                | home: http://www.utu.fi/~juolja/              |
                 -----------------------------------------------

Attachment: pgpEKQ8pLE0nb.pgp
Description: PGP signature

Reply via email to