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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
