Sitting on an almost well configured host, I experienced some authentication issues the last few days…

So for example I’m using xtrlock as default X locking mechanism, but if I try to run it on this machine I got the following error:

Mmh, that is crap. My workaround to temporarily avoid this problem: Connecting to another host via SSH, running xtrlock within a GNU screen session ;-) But that’s no solution for a longer time… So I started debugging. First of all I grabbed the sources from the apt repository and searched for this error message. Turned out to be this piece of code (beginning with line 94 of xtrlock.c ):

Ok, seems that the provided password(-hash) is shorter than 13 characters… Going on debugging, the content of pw comes from getpwuid(getuid()) and seems to be ok (matches my users profile like it can be found in /etc/passwd ). At this time (line 1) pw->pw_passwd contains only an single x , more information can’t be retrieved from the passwd -file.. Next the code checks whether SHADOW_PWD is defined, means whether we use an additional shadow -file. Since thats the case this code is executed and the variable sp gets the broken-out fields of the record in the shadow password database that matches the username pw->pw_name (validated, my user). Checking this sp variable I recognized that it is null ! So pw->pw_passwd won’t be updated and still contains the single x from the passwd entry… First I thought about a bug in the getspnam () function, such things might happen due to the Debian unstable release I’m using, but after some further thoughts I checked the shadow file itself:

In comparison with other systems with working xtrlock instances I figured out, that this file shouldn’t only be owned by root. Instead the group has to be shadow! So here is the solution to this issue:

And everything is working fine again. Have no idea what or who changed the permissions for the shadow-file…

Update: By the way, afterwards I tried to use Xscreensaver instead of xtrlock, but I wasn’t able to unlock the screen when the shadow rights are wrong. The /var/log/auth.log held messages like that:

But this is just for google-searchers ;-)

Markus | Permalink | 2013-05-02 19:05:08

Thanks a lot. Just moved my system to a new HDD and xscreensaver wouldn’t accept my password. Without you I would stillt be looking all over the web for the solution :)

Tom Andrews | Permalink | 2017-01-02 01:57:00

Thank you very much for the shadow file clue. Mine was both owned and group root and mode 400 (read only, root only). Changed it to group shadow and mode 640 (read,write root and read shadow). Now I can unlock with xtrlock and xscreenlock using shadow passwords. Like you, I have NO IDEA how the permissions and group were altered to begin with. May be legacy since the OS has been upgraded many times.