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):
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.
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]
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
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'
[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
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
[root@slacker ~]# rpm -V pam
S.5....T. c /etc/pam.d/system-auth
..?...... c /etc/security/opasswd
unlocking screensaver with root password & tomg user:
Sep 12 19:33:33 slacker xscreensaver(pam_unix): authentication failure;
logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=tomg
<blank, nothing added>
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
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.
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.