> 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 :/ > At the moment, it doesn't seem we have any recourse for you other than > to disable RHA with the -D policy option. We do like RHA for its security, so right now we just let users double-unlock. (We don't have smart card users right now.) > 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 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/ Does pam_sunray.so set the password in PAM_AUTHTOK like pam_authtok_get otherwise would? 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). William _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
