... that is, if an ordinary user locks their X session (so that XScreensaver requires a password to unlock), Xscreensaver/PAM allow anyone at the screen to enter the users password or the root pass to unlock the session. I don't know if this is a bug or an undocumented feature, but this behaviour is different to that of RH 7.3 and Mandrake 8.2 and seems odd to say the least. Details follow: System: Gentoo Base System version 1.4.2.5 x11-misc/xscreensaver-4.06-r2 sys-libs/pam-0.75-r10 /etc/pam.d/xscreensaver: #%PAM-1.0 auth required /lib/security/pam_stack.so service=system-auth debug Added by me to try to understand what's going on here--------------------^ Here is an example of the behaviour with added commentary: I log into my box as 'steph', and when I lock my screen and then unlock it, I get nothing logged to syslog unless I have the debugging turned on. This is default behaviour I guess as my pam probably aren't set up to log successes. Anyways, I noticed this when I accidentally tried to unlock 'steph's' locked screen using the root password rather that steph's: from auth.log: Dec 30 14:52:36 heroditus xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost= user=steph Dec 30 14:52:38 heroditus xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost= user=root Now as my username was steph and I entered the wrong password the above would be normal; but the problem is; it unlocked the screen. Now I think there is something fishy going on here, so I turn on debugging for that pam module and the following happens when I lock and unlock my ('steph'; UID 100) screen as 'root': (cleaned up so it doesn't wrap horribly) **note that Xscreensaver forces me to leave the username as is; that is, I am now attempting to authenticate as 'steph' using root's password: pam_stack[10255]: called for "PAM_AUTHENTICATE" pam_stack[10255]: called from "xscreensaver" pam_stack[10255]: initializing pam_stack[10255]: creating child stack `system-auth' pam_stack[10255]: creating environment pam_stack[10255]: NOT passing PAM_AUTHTOK to child: source is NULL pam_stack[10255]: passing PAM_CONV to child pam_stack[10255]: passing PAM_FAIL_DELAY to child pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to child: source is NULL pam_stack[10255]: NOT passing PAM_RHOST to child: source is NULL pam_stack[10255]: NOT passing PAM_RUSER to child: source is NULL pam_stack[10255]: passing PAM_SERVICE to child pam_stack[10255]: passing PAM_TTY to child pam_stack[10255]: passing PAM_USER to child pam_stack[10255]: NOT passing PAM_USER_PROMPT to child: source is NULL pam_stack[10255]: passing data to child pam_stack[10255]: calling substack xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost= user=steph pam_stack[10255]: substack returned 7 (Authentication failure) pam_stack[10255]: passing PAM_AUTHTOK to parent pam_stack[10255]: NOT passing PAM_CONV to parent: destination already set pam_stack[10255]: passing PAM_FAIL_DELAY to parent pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to parent: source is NULL pam_stack[10255]: NOT passing PAM_RHOST to parent: source is NULL pam_stack[10255]: NOT passing PAM_RUSER to parent: source is NULL pam_stack[10255]: passing PAM_SERVICE to parent pam_stack[10255]: passing PAM_TTY to parent pam_stack[10255]: passing PAM_USER to parent pam_stack[10255]: NOT passing PAM_USER_PROMPT to parent: source is NULL pam_stack[10255]: passing data back pam_stack[10255]: passing former back pam_stack[10255]: returning 7 (Authentication failure) pam_stack[10255]: called for "PAM_AUTHENTICATE" pam_stack[10255]: called from "xscreensaver" pam_stack[10255]: initializing pam_stack[10255]: found previously-used child stack `system-auth' pam_stack[10255]: NOT passing PAM_AUTHTOK to child: source is NULL pam_stack[10255]: NOT passing PAM_CONV to child: destination already set pam_stack[10255]: passing PAM_FAIL_DELAY to child pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to child: source is NULL pam_stack[10255]: NOT passing PAM_RHOST to child: source is NULL pam_stack[10255]: NOT passing PAM_RUSER to child: source is NULL pam_stack[10255]: passing PAM_SERVICE to child pam_stack[10255]: passing PAM_TTY to child pam_stack[10255]: passing PAM_USER to child pam_stack[10255]: NOT passing PAM_USER_PROMPT to child: source is NULL pam_stack[10255]: passing data to child pam_stack[10255]: calling substack xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost= user=root pam_stack[10255]: substack returned 7 (Authentication failure) pam_stack[10255]: passing PAM_AUTHTOK to parent pam_stack[10255]: NOT passing PAM_CONV to parent: destination already set pam_stack[10255]: passing PAM_FAIL_DELAY to parent pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to parent: source is NULL pam_stack[10255]: NOT passing PAM_RHOST to parent: source is NULL pam_stack[10255]: NOT passing PAM_RUSER to parent: source is NULL pam_stack[10255]: passing PAM_SERVICE to parent pam_stack[10255]: passing PAM_TTY to parent pam_stack[10255]: passing PAM_USER to parent pam_stack[10255]: NOT passing PAM_USER_PROMPT to parent: source is NULL pam_stack[10255]: passing data back pam_stack[10255]: passing former back pam_stack[10255]: returning 7 (Authentication failure) Dec 30 15:11:21 heroditus pam_stack[10255]: freeing stack data for `system-auth' service By this point the screen is unlocked. Again, I don't know if this is a bug or an undocumented feature, but it differs from the behaviour of the other distros and is a slight cause for concern from a security standpoint that it allows people to attack the root passwd irrespective of things like pam_wheel.so. I'm more than willing to provide any further information if required. Cheers, Steph
this is expected behaviour. use xlock if you don't like it
I am not 100% sure on this. We do use similar /etc/pam.d/system-auth as Redhat/Mandrake. Seemant, got a Redhat/Mandrake box with recent version of distro that you can test this on with similar xscreensaver/kscreensaver pam.d files ?
The whole thing strikes me as odd. I re-read the manpage and Seemant was indeed correct: "...it will require you to type the password of the logged-in user (really, the person who ran xscreensaver), or the root password..." Now that seems pretty silly to me, but, if that's what the xscreensaver authors say, tehn so be it. Buuuut RH 7.3(xscreensaver 3.33-4, pam-0.75-32), Mdk 8.2(4.00-4mdk,0.75-20mdk), RH 8.0 (4.05-6,0.75-40) all behave differently (that is, the root pass cannot unlock a user-locked screen). All have identical pam.d/xscreensaver entries. A cursory look at the RH 8.0 pam.d/system-auth vs. my current system-auth says they're identical.
Pam should be fairly the same as well as Redhat's, As I try to keep in sync with security/bugfixes. We do have one or two extra patches for segfaults, etc, but those they have not responded on. Could be that they patch xscreensaver/kscreensaver side. Ill have a look. Ill just recheck their patches to pam, but I did so about 3 weeks ago ...
Just an interjection. I'd suggest the manpage is completely correct and that this is exactly the way it's supposed to work. Consider: 1) RH generally responds to their _business users_ requests. 2) Assume a companiy's standard security policy requires users be automatically forced to change their passwords monthly. Imagine how many users forget their new passwords after the screensaver comes on. ... While this functionality may not make sense in a SOHO or single user environment, it is an essential business requirement. Hope this helps.
Right, it is intended behaviour.