[OpenAFS] pam-afs-session 0.1 released

[Douglas E. Engert]

Looking good. But at least read the final comment that really addresses
a lot of the other issues, like abstraction, syscall numbers and non-linux
systems.

Russ Allbery wrote:

> 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.

Yes, this is a problem with all the aklog programs, You cant specify
get a token for the default cell of the machine and for the cell that
contains the user's home directory. A partial fix is if the home
directory is not in /afs then don't use the -p option.

> 
> (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.)

Actually it can be a script. Very handy for debugging.

> 
> 
>>  * 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.

I say a lot of PAM_SESSION_ERR. For example, if the aklog program can
not be found, or the return status is not zero.

> 
> 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.
> 

OK, I will buy a failed PAG, but not a failed token. But why would the PAG
fail? The main reason would faiulure of the kernel extensions to load,
afsd did not start (yet).

> 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.
> 

I agree.

>>  * 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.


Another way to do this, is to make this routine part of OpenAFS,
as it has no Kerberos code and only depends on OpenAFS.
In effect your sys-linux.c code is the OpenAFS src/sys/setpag.c
and src/sys/glue.c They already have headers and the syscall number.

(The pam_afs2 calls the gafstoken routine that used to
work on AIX, and not fail if AFS was not load. But we don't
have any AIX systems any more. We had the MIT r* commands
calling gafstoken at the right time.)

> 
> 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.

OK, that will work.

> 
> 
>>     (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.

We are down to one HP system so HP is not important to us at least.

> 
> 
>>     (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?

Depends on the compiler and how it passes options to the loader.
You also have the option of using either the GNU loader or the Solaris
loader. Most site use the Solaris loader even with gcc.
Gets real mesy, but not as bad as on HP.

(libtool tries to address a lot of these issues. I am not saying use
libtool. But also see the final comments about distribution.)

If you are using GCC, you need the -W...
If you are using the Solaris compiler, then you don't.
(I have not tried building this with the Solaris compiler.)

> 
> 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.
> 

If you just use the OpenAFS src/sys/glue.c and src/sys/setpag.c there is no
need for an abstraction.

There should be no need for a seperate distribution, as OpenAFS could
could do all of this, as this PAM routine has no kerberos code, only
OpenAFS code.


-- 

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