From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3 Description of problem: After accidentally typing in my previous password to break the screen lock, I discovered that both my and new passwords break the screen lock. Version-Release number of selected component (if applicable): xscreensaver-4.18-4 How reproducible: Always Steps to Reproduce: 1. Lock screensaver 2. Enter previous linux password 3. Actual Results: The screen lock was broken Expected Results: An error stating I used the wrong password. Additional info: I'm not sure what other info to provide, except that I tried creating a new password with the "passwd" command and that didn't clear things up. Please advise on what other info is needed to investigate further.
Hmm... I can't reproduce this. As far as I know, xscreensaver doesn't cache the user's password information. I'm fairly confident it just sends the info off to PAM. If you go to a virtual console (by pressing ctrl-alt-f1) can you log in with either password? Are you using some sort of network authentication (kerberos, ldap, etc) or is this just an account that is local to the machine?
Never mind, sorry for wasting your time. I figured it out--the stupid previous password was the same as my root password, which of course can break the screen lock! I've been su'ing into root for so long that I haven't properly logged in as root in a while....I'm really sorry for opening this bug report and bothering you. You can close it now.
Actually, the root password shouldn't be able to break the screen lock. That causes various security problems. It doesn't seem to work for me--can you do some tests and confirm that it works for you?
I checked it both on my work laptop, which also runs FC3 & no network authentication, and my home computer, and the root password breaks the screen lock on both.
retitling for clarity
can you attach your /etc/pam.d/system-auth file please?
Created attachment 114533 [details] /etc/pam.d/system-auth file system-auth file attached.
The same problem exists in FC4 Release on my HP nc6000 laptop.
This can work only if you use different authentication scheme than shadow passwords to authenticate the root user. With a shadow password for root (and properly set permissions for /etc/shadow) it shouldn't be possible to unlock screensaver with root password. As you don't have any network authentication in system-auth, the questions are - what permissions are on your /etc/shadow, what 'getent passwd root' prints?
[root@slacker ~]# ls -ld /etc/shadow -r-------- 1 root root 1035 Sep 4 23:24 /etc/shadow [root@slacker ~]# getent passwd root root:x:0:0:root:/root:/bin/bash [root@slacker ~]#
More questions then - what 'getent shadow root' returns if run as the normal user? And are you sure that you don't use acls on /etc/? (What 'getfacl /etc/shadow' prints?)
[tomg@slacker 0 ~]$ getent shadow root [tomg@slacker 2 ~]$ Looks like I get an #2 exit status when run as me (my prompt has the exit status of the last command in it). If I'm using ACLs, it's news to me. I'm pretty lazy when it comes to installing--I just go for a software/sysadmin workstation setup and take whatever defaults come my way. [root@slacker ~]# getfacl /etc/shadow getfacl: Removing leading '/' from absolute path names # file: etc/shadow # owner: root # group: root user::r-- group::--- other::--- [root@slacker ~]# Since it has been awhile since I reported this, I just thought you should know that update my system regularly with the latest RPMs from the updates-released yum repos. I'm pretty diligent in applying the latest patches.
This is really strange. What pam version do you have and what rpm -V pam reports? Also could you try to unlock the screen lock with the root password again and report what was added to the /var/log/messages and /var/log/secure logs?
[root@slacker ~]# rpm -q pam pam-0.79-9.5 [root@slacker ~]# rpm -V pam S.5....T. c /etc/pam.d/system-auth ..?...... c /etc/security/opasswd [root@slacker ~]# unlocking screensaver with root password & tomg user: messages: Sep 12 19:33:33 slacker xscreensaver(pam_unix)[2587]: authentication failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=tomg secure: <blank, nothing added>
One more thing: I noticed that there were 2 system-auth files in /etc/pam.d: system-auth system-auth.rpmnew I tried switching them around to see if the system-auth.rpmnew made any difference, but it didn't. The current rpm -V output is now: [root@slacker pam.d]# rpm -V pam .......TC c /etc/pam.d/system-auth ..?...... c /etc/security/opasswd
I spent some time looking into this today. If I enable SELinux on my FC4 machine, I can use my password, or the root password to unlock the screen. With SELinux disabled I can only use my password to unlock the screen.
This is a side effect of bug 168180. Xlock tries to use the root password to unlock but unix_chkpwd refuses to check when selinux is disabled. When it is enabled it checks. unix_chkpwd is being fixed to work the same with or without selinux, but xlock should ifdef out the code that tries to login as root. Dan
Hi Tom, This issue should be fixed in tomorrow's rawhide.
Ray, you said: > Actually, the root password shouldn't be able to break the screen lock. That > causes various security problems. Um... no it doesn't, it just thows a pointless and easy-to-circumvent roadblock in front of the admin. If someone who *knows the root password* wants to un-lock the screen, they can do it any number of ways. First, they can just type the root password into xscreensaver. Or, if you've decided to disable that, then they can go to a VT, log in as root, and do "killall xscreensaver". That latter is worse because: A) now the admin is annoyed that they had to do so much more typing for no reason; B) now xscreensaver is no longer running at all, meaning the screen will not auto-re-lock, and security has been reduced.
Sorry Jamie but you are not right. Without a trusted path (such as Ctrl+Alt+Del key combo in Windows) which would open a trusted password dialog I as root cannot simply enter my password to user's xscreensaver. It could easily log the root's password for the user. The switch to another console provides the trusted path. To solve the problem B you could for example provide a signal handler for SIGUSR1 which would only unlock the screensaver and didn't kill it.