xscreensaver unlock fails

[z3non]

Binary package hint: xscreensaver

xscreensaver doesn't unlock my screen, I've to switch to a console and kill the xscreensaver-process to regain access to my desktop ..

I'm using xfce (xubuntu), having no special pam setup.

auth.log:
Oct 7 12:15:30 silver unix_chkpwd[9713]: check pass; user unknown
Oct 7 12:15:30 silver unix_chkpwd[9713]: password check failed for user (tom)
Oct 7 12:15:30 silver xscreensaver: pam_unix(xscreensaver:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=tom
Oct 7 12:15:32 silver xscreensaver[9612]: FAILED LOGIN 1 ON DISPLAY ":0.0", FOR "tom"

regards,
tom

[z3non (tom-uttenthaler)]

I found out, that the problem lies in the permissions of /etc/shadow resp. /sbin/unix_chkpwd

I assume, /etc/shadow should be owned by the group 'shadow', but for some reason it had this permissions:

$ ls -l /etc/shadow
-rw-r----- 1 root root 1133 2008-10-06 19:32 /etc/shadow

after doing
$ sudo chgrp shadow /etc/shadow

it worked, as the program 'unix_chkpwd' has the GUID bit set and is owned by the group shadow:
$ ls -l /sbin/unix_chkpwd
-rwxr-sr-x 1 root shadow 30272 2008-09-23 09:06 /sbin/unix_chkpwd

This should be fixed for hardy & intrepid, as I had this problem on both versions and there are various bug reports out there about similar problems (e.g. #92932)

regards,
tom

[Tormod Volden (tormodvolden)]

/etc/shadow is root:shadow by default in Ubuntu 8.10 at least. Is it tempting to believe it's your setup that is broken. Let's reopen the bug only if somebody else also has this problem.

[z3non (tom-uttenthaler)]

Tormod Volden schrieb:
> /etc/shadow is root:shadow by default in Ubuntu 8.10 at least. Is it
> tempting to believe it's your setup that is broken. Let's reopen the bug
> only if somebody else also has this problem.

You're right, my setup is (was) broken - but I promise, I didn't break
this by hand, but through Ubuntu upgrades - so my approach to
Software-QA is, that if something has been automatically broken, the
system should at least try to automatically fix it - in this case, it
would probably a two liner in the installation scripts.

There have been several reports about this problems (e.g. [1]), seems it
has been introduced with the upgrade to hardy. In most cases people fix
it by seting SUID-Bit for the screensaver/-locker program, insted of
setting /etc/shadow right ...

To me it seems there are many ubuntu installations around with a f*cked
up /etc/shadow permission setup, so it would definitely be no
disadvantige to recheck it during a package upgrade.

regards,
tom

[1] https://bugs.launchpad.net/ubuntu/+source/kde-guidance/+bug/26175

[Tormod Volden (tormodvolden)]

If you think this can be reproduced or confirmed by other users, please file a bug report, on the "base-passwd" package.

[Luca A (luca-azzalini)]

I can confirm this is a bug of Ubuntu Hardy/Intrepid.
I had exactly the same situation of z3non, that is:

$ ls -l /etc/shadow
-rw-r----- 1 root root 1133 2008-10-06 19:32 /etc/shadow

After applying z3non's solution the problem disappeared.

I'm sure I haven't changed permission on /etc/shadow by myself. This is a Hardy install upgraded to Intrepid

Thanks a lot to z3non for his helpful post.