Issue 36 in nsscache: xscreensaver won't unlock

[nssc...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 36 by j...@trackuino.org: xscreensaver won't unlock
https://code.google.com/p/nsscache/issues/detail?id=36

What steps will reproduce the problem?
1. Start an X session as some user in the nsscache database (I'm using
Linux Mint/XFCE, nsscache uses the "files" cache style)
2. Lock the screen with xscreensaver
3. Try to unlock by entering the password

What is the expected output? What do you see instead?

I should be back to my X session. Instead, I get a "authentication failure".

What version of the product are you using? On what operating system?

nsscache 0.23-2 on Linux Mint 17 (Xfce) (default package installed via
apt-get)

Please provide any additional information below.

The problem appears to be that xscreensaver uses pam_unix for user
authentication, and pam_unix apparently requires shadow files to be owned
by group "shadow". Ownership of the original files should be preserved
across the cache files. Currently only permission bits are preserved.

Attached proposed patch, which copies ownership (uid/gid) data over to the
cache files in addition to perm bits.

Tested and working with "files" cache. Not tested with berkeley db style
cache.

Attachments:
nss_cache_chown.patch 1.2 KB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[nssc...@googlecode.com]

Comment #1 on issue 36 by binanh.a...@gmail.com: xscreensaver won't unlock
https://code.google.com/p/nsscache/issues/detail?id=36

Hello

Did you cache the shadow and could be authenticated normally on pam ?

[nssc...@googlecode.com]

Comment #2 on issue 36 by j...@trackuino.org: xscreensaver won't unlock
https://code.google.com/p/nsscache/issues/detail?id=36

I've tried with pamtester and it doesn't work either:

baca@PC2101 ~ $ ls -l /etc/shadow.cache*
-rw-r----- 1 root root 125392 sep 15 21:02 /etc/shadow.cache
-rw-r----- 1 root root 27869 sep 15 21:02 /etc/shadow.cache.ixname
baca@PC2101 ~ $ pamtester login baca authenticate
Password:
pamtester: Authentication failure


Relevant lines in auth.log:

PC2101 ~ # tail -3 /var/log/auth.log
Sep 16 13:23:53 PC2101 unix_chkpwd[13229]: check pass; user unknown
Sep 16 13:23:53 PC2101 unix_chkpwd[13229]: password check failed for user
(baca)
Sep 16 13:23:53 PC2101 pamtester: pam_unix(login:auth): authentication
failure; logname=baca uid=10714 euid=10714 tty= ruser= rhost= user=baca


After 'chgrp shadow /etc/shadow.cache*' authentication works normally:

baca@PC2101 ~ $ ls -l /etc/shadow.cache*
-rw-r----- 1 root shadow 125392 sep 15 21:02 /etc/shadow.cache
-rw-r----- 1 root shadow 27869 sep 15 21:02 /etc/shadow.cache.ixname
baca@PC2101 ~ $ pamtester login baca authenticate
Password:
pamtester: successfully authenticated


Note that if I run pamtester as root, it works regardless of the cache
files' ownership:

PC2101 ~ # ls -l /etc/shadow.cache*
-rw-r----- 1 root root 125392 sep 15 21:02 /etc/shadow.cache
-rw-r----- 1 root root 27869 sep 15 21:02 /etc/shadow.cache.ixname
PC2101 ~ # pamtester login baca authenticate
Password:
pamtester: successfully authenticated
PC2101 ~ #


But this is not the case with xscreensaver, which runs as the logged in
user.

[nssc...@googlecode.com]

Comment #3 on issue 36 by j...@trackuino.org: xscreensaver won't unlock
https://code.google.com/p/nsscache/issues/detail?id=36

Just a piece more of info, it looks like the ultimate reason why
/etc/shadow* must be chgrp'ed shadow is because /sbin/unix_chkpwd (used by
pam_unix) is setgid shadow:

PC2101 ~ # ls -l /sbin/unix_chkpwd
-rwxr-sr-x 1 root shadow 30432 ene 31 2014 /sbin/unix_chkpwd

[Berend De Schouwer]

On Tue, 16 Sep, 2014 at 2:15 , nssc...@googlecode.com wrote:
>
> Comment #3 on issue 36 by j...@trackuino.org: xscreensaver won't
> unlock
> https://code.google.com/p/nsscache/issues/detail?id=36
>
> Just a piece more of info, it looks like the ultimate reason why
> /etc/shadow* must be chgrp'ed shadow is because /sbin/unix_chkpwd
> (used by pam_unix) is setgid shadow:

I kinda like the symmetry of having /etc/shadow* all having the same
permissions. The permissions and ownership should get copied from
/etc/shadow, unless there's a good reason not to.

> PC2101 ~ # ls -l /sbin/unix_chkpwd
> -rwxr-sr-x 1 root shadow 30432 ene 31 2014 /sbin/unix_chkpwd

For interest's sake, this file is 1755 on RedHat/Fedora, so it will
work regardless of permissions on the files.

/etc/shadow on Fedora is 000 (no-one can read) so unix_chkpwd must be
root.

The pam_unix module expects to be root for some operations, since it
has to lock /etc/passwd and saves a file to /etc/ to do that. This is
likely unnecessary for xscreensaver.

[nssc...@googlecode.com]

Updates:
Status: Fixed
Owner: j...@spacepants.org

Comment #4 on issue 36 by j...@spacepants.org: xscreensaver won't unlock
https://code.google.com/p/nsscache/issues/detail?id=36

Applied in github master.