Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 157014

Summary: root password works when unlocking screen
Product: [Fedora] Fedora Reporter: Tom Georgoulias <tom.georgoulias>
Component: xscreensaverAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: bressers, jwz, rick.zhong, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-16 20:43:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
/etc/pam.d/system-auth file none

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):

How reproducible:

Steps to Reproduce:
1. Lock screensaver
2. Enter previous linux password

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@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'

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

[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
[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:

Sep 12 19:33:33 slacker xscreensaver(pam_unix)[2587]: authentication failure;
logname= uid=500 euid=500 tty=:0.0 ruser= rhost=  user=tomg

<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:


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.


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.