|Summary:||root password works when unlocking screen|
|Product:||[Fedora] Fedora||Reporter:||Tom Georgoulias <tom.georgoulias>|
|Component:||xscreensaver||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Version:||3||CC:||bressers, jwz, rick.zhong, tmraz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-09-16 20:43:19 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Tom Georgoulias 2005-05-06 00:03:23 UTC
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.
Comment 1 Ray Strode [halfline] 2005-05-06 01:07:18 UTC
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?
Comment 2 Tom Georgoulias 2005-05-06 02:17:37 UTC
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.
Comment 3 Ray Strode [halfline] 2005-05-06 13:58:34 UTC
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?
Comment 4 Tom Georgoulias 2005-05-08 14:14:40 UTC
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.
Comment 5 Matthias Clasen 2005-05-18 17:34:23 UTC
retitling for clarity
Comment 6 Ray Strode [halfline] 2005-05-18 19:41:04 UTC
can you attach your /etc/pam.d/system-auth file please?
Comment 7 Tom Georgoulias 2005-05-18 20:49:22 UTC
Created attachment 114533 [details] /etc/pam.d/system-auth file system-auth file attached.
Comment 8 Rick Zhong Liming 2005-06-20 01:47:56 UTC
The same problem exists in FC4 Release on my HP nc6000 laptop.
Comment 9 Tomas Mraz 2005-09-09 21:13:56 UTC
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?
Comment 10 Tom Georgoulias 2005-09-09 21:39:55 UTC
[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 ~]#
Comment 11 Tomas Mraz 2005-09-09 21:47:31 UTC
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?)
Comment 12 Tom Georgoulias 2005-09-10 01:25:04 UTC
[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.
Comment 13 Tomas Mraz 2005-09-12 07:26:23 UTC
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?
Comment 14 Tom Georgoulias 2005-09-12 23:34:10 UTC
[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): authentication failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=tomg secure: <blank, nothing added>
Comment 15 Tom Georgoulias 2005-09-12 23:49:29 UTC
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
Comment 16 Josh Bressers 2005-09-16 18:23:25 UTC
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.
Comment 17 Daniel Walsh 2005-09-16 19:29:42 UTC
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
Comment 20 Ray Strode [halfline] 2005-09-16 20:43:19 UTC
Hi Tom, This issue should be fixed in tomorrow's rawhide.
Comment 21 Jamie Zawinski 2006-05-15 04:49:47 UTC
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.
Comment 22 Tomas Mraz 2006-05-15 06:55:59 UTC
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.