The hunt for /etc/.pwd.lock#
After upgrade Debian to kernel 3.0.0, I saw a hidden file called
/etc which I didn’t noticed before. Checking other machines gave the same result as shown below, but both without a matching Debian-package or manpage.
$ ls -l /etc/.pwd.lock -rw-------. 1 root root 0 feb 27 2009 /etc/.pwd.lock $ ls -l --time=atime /etc/.pwd.lock -rw-------. 1 root root 0 apr 10 2010 /etc/.pwd.lock $ ls -l --time=ctime /etc/.pwd.lock -rw-------. 1 root root 0 aug 14 2010 /etc/.pwd.lock
As time match at least the installation date of the machine and exists on other machines it appears to be a valid file, but with what purpose? After reading the Linux Programmer’s Manual two functions called lckpwdf and ulckpwdf where candidates for using this file. Checking the source code at Sourceware confirmed that both lckpwdf and ulckpwdf are using the file. And reading the manpage about these functions also confirms its purpose, a lock file the commands like passwd.
The lckpwdf() function is intended to protect against multiple simultaâ€neous accesses of the shadow password database. It tries to acquire a lock, and returns 0 on success, or -1 on failure (lock not obtained within 15 seconds). The ulckpwdf() function releases the lock again. Note that there is no protection against direct access of the shadow password file. Only programs that use lckpwdf() will notice the lock.
These were the functions that formed the original shadow API. They are widely available.
This is another example of why open source matters. You can get the evidence when you want and/or need it instead of trusting some manual to explain things. Verification will become more important as systems get more complex. It was/is also a big advantage when OpenSolaris was created with its web-accessible source repository.