Categories
Internet, Unix en security

The hunt for /etc/.pwd.lock

After upgrade Debian to kernel 3.0.0, I saw a hidden file called .pwd.lock in /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 it’s 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 why open source matters. You can get the evidence when you want and/or need 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 it’s web accessible source repository.

Categories
Internet, Unix en security

Vaarwel, /etc/mtab?

Op BSD heb je /etc/mtab en op SVR heb je /etc/mnttab. Vreemd genoeg heeft men bij Linux gekozen voor de BSD oplossing terwijl de rest in de richting van SVR is. De andere vraag is of beide oplossingen nog wel nodig zijn nu ook alle informatie wordt aangeboden via /proc/mounts.

Nu steeds meer informatie netjes via /proc beschikbaar komt op Linux wordt het misschien tijd om oude gewoonten achter ons te laten. Het gebruik van dmidecode is al niet meer nodig en met bugreports worden scripts bij Debian nu omgeschreven om de kernel interface te gebruiken. Hopelijk volgen andere onderdelen ook en wordt /etc weer echt voor configuratie en niet ook voor semi-statische confirgutatie items.