Sorry; but I'm going to return us to this flamewar... --On Thursday, March 06, 2008 02:43:00 PM -0600 Nicolas Williams <Nicolas.Williams at sun.com> wrote:
> PAM modules may require any and all [zone] privileges. Using PAM > requires all [zone] privileges. This is a Solaris-ism. You need to get out of your Sun-only box and pay attention to the rest of the world for a bit. Usually I accuse Linux folks of being myopic in this way, but if the shoe fits... > This does not mean that you can't proxy PAM calls from one process to > another, if you really want -- arguably embedded_su(1) does just that). > But pam_setcred(3PAM) will only apply to the caller's process, not its > "client," so that is going to be an issue. Happily, in this case, not, > because the screen lock program always exits when the screen is unlocked > -- it certainly doesn't start sessions, but if it did those would have > to be fork()ed from the process that makes the PAM calls. This is an excellent reason for the process which calls PAM _not_ to be an external helper. As noted, screensavers don't open sessions. They do call pam_authenticate(), and may also call pam_setcred(PAM_REFRESH_CRED) -- for example, you really want a screensaver to do this when using a pam_krb5, so your tickets get refreshed when you unlock. For that to work, the caller of pam_setcred() needs to be able to manipulate the users' existing credential cache, _and_ it needs to be in the same process as the caller of pam_authenticate(), so the module can pass data back and forth. The easiest way to accomplish this is to insure that PAM modules, or at least those which make sense in this context, can support pam_authenticate and (where appropriate) pam_setcred(PAM_REFRESH_CRED) even when called without privilege. A screensaver is an application, though a slightly specialized one. Users should not be restricted to running applications which ship with the OS or were "blessed" by a system administrator. Restricting me to running gnome-screensaver is insane. -- Jeff
