[OpenAFS] pam-afs-session 0.1 released

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:

> Feature requests:

>   * all aklog type programs support the -p <path> option, so that
>     the user's home directory can be passed, so a token for the
>     user's cell can be obtained.

This isn't good default behavior since, for instance, it will fail to get
tokens when the user's home directory isn't in AFS.  I added an option to
request this behavior, though.

(At some point, I'm going to have to figure out what to do if the program
to run isn't a simple program name but has some options attached.  Oh
well, I can put that off for right now.)

>   * Should a failure to get a PAG or token be a critical failure?
>     i.e. if the routine is called on a system without AFS, or the
>     AFS kernel extensions failed to load, which should sshd do?
>     I would say continue on, but log a message. You return
>     PAM_SESSION_ERR in a lot of these situations. Should this be
>     an option?

Well, those are two different questions.

If AFS isn't available, the module should log a message and return
success.  That's what it does now.

If AFS *is* available, but the module was unable to obtain a PAG, it
should fail.  Otherwise it could introduce a security vulnerability, by
leaving the user in the same PAG as sshd, for instance.

Not obtaining the token is more borderline, but after thinking about it
for a moment, I think it makes more sense to log an error message and then
return success.  I'd rather not make this an option unless that strikes
someone as bad behavior for their environment.

>   * Add support to trap signals around any calls to the AFS kernel
>     extensions. This really only applies if syscall is used. This
>     will keep a failure of AFS to load for keeping login to work.

I was going to punt on anything other than Linux for the built-in AFS
syscall support, but after thinking about, I think I can get the system
call number from the OpenAFS headers and add the other syscall testing
code for the systems where this is easy.  That won't cover AIX, but AIX
doesn't use PAM anyway so far as I know.

I'm going to work on this next.

>   * Don't allow the aklog program to write to stdout or stderr,
>     as the messages may be misinterpreted by the client, rsh for
>     example could have problems. Something like this is the
>     exec'ed process:

>         close(1); open("/dev/null",O_WR_ONLY");
>         close(2); open("/dev/null",O_WR_ONLY");

Done.

>   * You specifically check for KRB5CCNAME, and only call the aklog
>     if it is present. It is really up to the aklog program to find
>     the credentials, and it should still be called.

I don't agree for the default behavior; I don't want aklog picking up some
random Kerberos ticket cache and obtaining tokens that may potentially be
wrong.  However, I've added an option saying to always run aklog that
people can turn on if they choose.

>      (1) On some systems like HP_UX that does not support pam_env,
>          the KRB5CCNAME may not be set, yet tickets are available,
>          using the default uid based cache name.

This is a different problem that should be solved by the PAM module
creating a KRB5CCNAME for HP-UX in that case when possible, probably using
the same method that you use in pam_afs2.  That's on my list to look at,
but isn't one of my top priorities.

Is there any hope that HP-UX will add the PAM environment functions?  I
suppose hoping for HP-UX to join the modern world is kind of doomed at
this point; it's probably a mostly dead OS as development goes judging
from the direction of HP's products.

>      (2) You are assuming that Kerberos is required. There are some
>          AFS sites that run Globus, and use gssklog with the GLOBUS
>          GSI using certificates to get an AFS token.

Right, those sites should use the new option.

>   * Do you want to call it pam_afs_session? Sam's routine has the same
>     name. Should you use a different name? Your routine can be also be
>     called from auth for pam_setcred. So why does it have _session?
>     How about pam_afs3.

Sam's module is called pam_openafs_session (or pam_openafs-krb5 in its
source).  I picked pam_afs_session so that it doesn't conflict.

pam_setcred is actually a session function as far as I'm concerned.  I'm
not sure why PAM stuck it in the auth group, and we're stuck with that
now, but I don't think it's inconsistent for a session module to provide a
pam_sm_setcred.

I'd rather avoid something generic like pam_afs3; for one, afs3 is a
specific protocol and that may confuse people, and for another, it doesn't
say much about what the module does.  I would just call it pam_aklog
except that I plan on adding support (optional) for calling the kafs
functions to obtain tokens directly.

> +*-solaris*)
> +	if test "x${CC}" = xgcc ; then
> +		LDFLAGS="-Wl,-z,muldefs $LDFLAGS"
> +	else
> +		LDFLAGS="-z muldefs $LDFLAGS"
> +	fi
> +	;;
>  esac

This looks wrong.  Why do you have to allow for multiply-defined symbols
on Solaris?

The other header changes have been applied, and I'm working on the syscall
abstraction now.  As soon as I finish that and write a man page, I'll
release a 0.2 release.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>