William Yang schrieb:
Unfortunately, this seems to be a chicken-and-egg issue. In the extreme
case, we can't authenticate you in a separate session if the PAM
authentication modules have tight, unconstrained dependencies on the
session context itself. We could do a couple of things in this area to
get closer, but the general case seems unsolvable. Luckily, few PAM
modules have such tight constraints, and thus almost all work fine with
RHA.
Security vs. security :/
:-/
Your answer to Joerg's question regarding AFS's store/cache method for
creds may help guide us to a better long-term solution for your PAM
model. Do you use pam_putenv()?
I actually had the impression that AFS uses somethign else that we can't
easily address.
I believe the pam_krb5 does do pam_putenv to set the KRB5CCNAME variable.
Source is available here: http://www.eyrie.org/~eagle/software/pam-krb5/
I thought so. Proper support for variables from pam_putenv in NSCM and
RHA is something that is still lacking, but should be doable.
Does pam_sunray.so set the password in PAM_AUTHTOK like pam_authtok_get
otherwise would?
No it does not. It maintains authentication state, but keeping the
cleartext password around to pass into the other session doesn't seem
such a good idea.
If it does, we may be able to work something out where the
xscreensaver stack looked like this instead:
xscreensaver auth required /opt/SUNWut/lib/pam_sunray.so syncondisplay
xscreensaver auth requisite pam_authtok_get.so.1
xscreensaver auth required pam_unix_cred.so.1 nowarn
xscreensaver auth sufficient /usr/local/lib/security/pam_krb5.so use_authtok
xscreensaver auth required pam_unix_auth.so.1
(as opposed to pam_sunray being sufficient) In that case, the user would
unlock the RHA dialog in the RHA stack, which would then pass the password
back to the xscreensaver stack and allow that to complete as if the user had
just typed in their password. Admittedly this makes it possible to shoot
oneself in the foot (if the two stacks don't match up you can succeed in one
but fail the other and get stuck).
Won't work. Other PAM modules probably use other way to transport
relevant data from pam_sm_authenticate to pam_sm_setcred, so that would
be a very partial solution anyhow.
- Jörg
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
