> >> 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.
That's right. AFS does not depend on environment variables. Tokens need to be refreshed inside the same PAG, somehow. > > 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. I'm not sure how this would help here, since wouldn't RHA just write to a different ccache than the one in use by the environment? > > 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. It could be a non-default PAM option like "pass_authtok" with a documented warning regarding possible security concerns. Would that be possible? > > 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. No? But if pam_sunray just appeared to do everything pam_authtok_get does in regards to the password, wouldn't that be sufficient? I feel like I'm missing something. Thanks, William _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
