Can't unlock session

Bug #26175 reported by DSeg
92
Affects Status Importance Assigned to Milestone
kde-guidance (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Unlocking KDE seesion fails with correct password.

A new session can be started and logged in with correct password.

(Any advice on where to find logs, or how to debug would be appreciated.)

Revision history for this message
DSeg (dropbox3) wrote :

This worked on original 5.10 install, but not after update/upgrade.

Revision history for this message
DSeg (dropbox3) wrote :

chmod 4755 /usr/bin/kcheckpass

solves the problem.

Is there an issue (security or otherwise) with this "fix" (or is this how it is
supposed to be)?

Revision history for this message
Matthew Gates (matthew-porpoisehead) wrote :

I get this too. Adding the deug option to the pam_unix.so module shows some
more information:

Dec 22 15:51:56 localhost unix_chkpwd[14298]: check pass; user unknown
Dec 22 15:51:56 localhost kcheckpass: (pam_unix) authentication failure;
logname= uid=1000 euid=1000 tty=/dev/pts/4 ruser= rhost= user=matthew
Dec 22 15:51:56 localhost kcheckpass[14297]: Authentication failure for matthew
(invoked by uid 1000)

The first line being the interesting one there I think. user unknown? I don't
know enough a PAM to have able to say what to do about it though. The setuid
root thing works, but I am un-easy about it.

Revision history for this message
Matthew Gates (matthew-porpoisehead) wrote :

Looking at /sbin/unix_chkpwd I noticed that is set-gid shadow, but the
/etc/shadow file had permissions that meant it could only be read by root:

-rwxr-sr-x 1 root shadow 14988 2005-09-12 19:12 /sbin/unix_chkpwd
-rw-r----- 1 root root 926 2005-12-16 22:07 /etc/shadow

I chowned /etc/shadow to be root:shadow, and now kcheckpass works properly
without having to be set-uid root. I'm not 100% sure if this change of group on
/etc/shadow has other implications, but it seems reasonable for it to be like this.

So now I have:
-rw-r----- 1 root shadow 926 2005-12-16 22:07 /etc/shadow
-rwxr-sr-x 1 root shadow 14988 2005-09-12 19:12 /sbin/unix_chkpwd
-rwxr-xr-x 1 root root 10048 2005-11-04 00:59 /usr/bin/kcheckpass

The only difference from the default install here is the group of the
/etc/shadow file. I think the installer is the culprit (I'm fairly sure I
didn't change it, unless the KDE user tools have done something without telling
me).

Revision history for this message
Fred Chu (zhuzhu) wrote :

yeah,

chmod 4755 /usr/bin/kcheckpass

very thanks.

Revision history for this message
Luka Renko (lure) wrote :

Matthew is right: GID of /etc/shadow is changed from group "shadow" to "root". This means that /sbin/unix_chkpwd does not have read access to /etc/shadow anymore.

I have modified GID back to "shadow" and everything works (I can unlock from any user, both GNOME and KDE). Then I have tried to add user with useradd, change passwd and similar and /etc/shadow GID was left intact. Good.
Then I tried to use System Settings -> Users & Groups and have seen that if I do any change (I have tried adding new user or deleting existing user) that GID of /etc/shadow is changed to "root". Unlock is broken again.

I think it is clear now that this is bug of kde-guidance. I will change the package and close all duplicate bugs.

Changed in meta-kde:
status: Unconfirmed → Confirmed
Revision history for this message
Simon Edwards (simon-simonzone) wrote :

This is fixed in version 0.6.3.

Changed in kde-guidance:
status: Confirmed → Fix Committed
Revision history for this message
Luka Renko (lure) wrote :

Fix released (checked with latest package)

Changed in kde-guidance:
status: Fix Committed → Fix Released
Revision history for this message
Jonathan Anderson (jonathan-anderson) wrote :

I just upgraded to Edgy, and this problem reared its ugly head again.

chmod fixed it, but it always worked for me in Dapper, and it shouldn't regress like this.

Revision history for this message
Nicholas Allen (nick-allen) wrote :

I only noticed this after installing edgy. Dapper didn't have this problem. The only solution seems to be to kill the X server and loose all your work!

Revision history for this message
Francesco Palermo (francesco-palermo) wrote :

I discover this bug when I upgrade from edgy to gutsy.

I fixed with:

# chgrp shadow /etc/shadow

because I saw that /etc/shadow permissions were:

# ll /etc/shadow
-rw-r----- 1 root utmp 1287 2007-10-15 15:00 /etc/shadow

Revision history for this message
pacesie (ne-pacesie) wrote :

Confirmed. This bug creeps in my fresh gutsy install on D630.

Revision history for this message
gcb (gcb0) wrote :

happening to me in gnome screensaver. only way back to the machine is to go to terminal and kill the gnome-screensaver processes.

Linux eeebook 2.6.24-21-eeepc #1 SMP Thu Aug 7 22:18:05 MDT 2008 i686 GNU/Linux

-rw-r----- 1 root shadow 911 2008-11-01 16:06 /etc/shadow

Revision history for this message
Zarah Mattox (wawalak) wrote :

This is also happening to me in gnome screensaver. Might be the same as Bug #299717 <https://bugs.launchpad.net/ubuntu/+bug/299717>.

EEE PC 1000
Linux 2.6.24-21-eeepc #1 SMP Thu Aug 7 22:18:05 MDT 2008 i686 GNU/Linux
-rw-r----- 1 root shadow 966 2008-12-14 13:56 /etc/shadow

Revision history for this message
Zarah Mattox (wawalak) wrote :

Found a fix in the following thread and Ubuntu EEE question #45385

http://ubuntuforums.org/showthread.php?t=804647
https://answers.launchpad.net/ubuntu-eee/+question/45385

Fix is as follows (from iLoveRuby's post on the thread):
CAUSE:
/sbin/unix_chkpwd and /etc/shadow have wrong group/permissions

SOLUTION:
chown root:shadow /sbin/unix_chkpwd
chmod 2755 /sbin/unix_chkpwd
chown root:shadow /etc/shadow

Revision history for this message
Scott Kitterman (kitterman) wrote :

This bug is marked fixed and has nothing to do with Gnome Screensaver. Please file a new bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.