Please help me solve one puzzle.

Long story short: "How do unix_chkpwd and kcheckpass manage to read from /etc/shadow if they run on behalf of a regular user and are not suid executables?"

And now for the long story...

It started with gentoo giving me issues after tar/untaring a working system to a new disk. The KDE screen locker wouldn't accept my password and would log errors in /var/log/auth.log like "check pass; user unknown" or "password check failed for user ...". Some googling revealed that the issue may be with /sbin/unix_chkpwd inability to read from /etc/shadow, and many were suggesting to just do a "chmod u+s /sbin/unix_chkpwd" as a workaround. Apparently on some other distributions this /sbin/unix_chkpwd was indeed an suid executable, but on my other "reference" gentoo install it wasn't, so I ignored that advice. In the end everything got fixed by just reemerging system/pam, that fixed something that tars were not able to preserve, and screen locker started to work normal again. But it still left me wondering about how this all machinery works.

Apparently when the screen is locked there are two processes. One is kscreenlocker_greet, which is showing the graphics and collecting the password. And the other one is kcheckpass. Both are started and are constantly running for as long as the screen lock is active. They're communicating through an AF_UNIX socket, and I can see the greeter passing my password to kcheckpass for validation. kcheckpass is loading a bunch of pam DLLs and is eventually spawning /sbin/unix_chkpwd, which validates password by reading /etc/shadow file.

What's bugging me is that kcheckpass appears to be running with my credentials. At least "ps -eo uid,euid,suid" shows UID 1000 and nothing else. An strace of kcheckpass reveals that it spawns /sbin/unix_chkpwd and is passing it my name for validation via arguments. Later it feeds my password to it via pipe. According to the traces that /sbin/unix_chkpwd subsequently manages to open /etc/shadow file just fine (even though /etc/shadow is owned by root:root and has 640 permissions). I don't see any suid executables in the chain, and the trace even shows a geteuid() call returning 1000 right before doing an execve(/sbin/unix_chkpwd).

So how in the world does this work? What mechanism am I missing here, and how do unprivileged processes manage to read from /etc/shadow file to validate my password?? I found some interesting read here (https://blog.martin-graesslin.com/blog/ ... en-locker/), that reveals that there is indeed some trickery going on, but still doesn't fully answer my question.

Oooooh, I'll answer my own question... It's not KDE-related at all. Turns out that even though unix_chkpwd isn't an suid program, it has fancy security capabilities associated with it. That also explains why things stopped working after tar/untar-ing the system: tar doesn't preserve them. This capability business is nasty though. Unless you know what to look for, you have no idea what's going on...

/sbin # ls -l unix_chkpwd
-rwx--x--x 1 root root 31184 Apr 25 19:53 unix_chkpwd

/sbin # getfacl unix_chkpwd
# file: unix_chkpwd
# owner: root
# group: root
user::rwx
group::--x
other::--x

/sbin # getcap unix_chkpwd
unix_chkpwd = cap_dac_override+ep

This post is a great help! I encountered the same problem in the same circumstance.

I took the time to register just to thank you - I have been looking for a solution for quite some time, thanks to your post I can now unlock KDE again!