OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: password file locking
From: Solar Designer (solarfalse.com)
Date: Sat Aug 26 2000 - 22:46:18 CDT

> > In recent Linux distributions, we have at least the following
> > packages that write to /etc/passwd:
> >
> > 1. pwdb (provides libpwdb, which is used by pam_pwdb).
> > 2. pam_unix (included with Linux-PAM).
> > 3. util-linux (provides chsh, chfn).
> > 4. shadow-utils (provides useradd and the like).

(Actually, it appears that calling this package "shadow-utils" is a
Red Hat'ism. It's called the "Shadow Password Suite" officially.)

> > Only #1 and #4 use compatible locking.

I failed to notice that shadow-utils uses two kinds of locking at
the same time, one of which is compatible with pam_unix. util-linux
remains a problem. Also, you can't use both pwdb and pam_unix on a
system.

> > All of these are found on at least RH 6.x. pam_unix isn't used by
> > default, but is often recommended on pam-list and apparently is
> > going to replace pam_pwdb in RH 7.x.
> >
> > Solutions?
> > 1. Move to a more consistent system. Bonus: consistent man pages.
> > 2. Patch util-linux, patch pam_unix.
> > 3. Patch util-linux, don't use pam_unix.
> > 4. Use the versions of chsh and chfn provided with shadow-utils
> > rather than ones provided with util-linux (any particular reason RH
> > prefers the util-linux versions?). Don't use pam_unix.

I'm using #4 for my PAM'ified systems now. Still need to "port" some
of the reliability fixes I did for libpwdb to the password file I/O
routines found in shadow-utils.

BTW, I still don't know why Red Hat prefers the util-linux versions.
The PAM support in chsh and chfn of shadow-utils seems to work fine
so far. vipw and vigr from shadow-utils also support editing of the
shadow files, which the util-linux versions don't.

> Ok, looked to source. It seemed to be the best is to use
> system-supplied locking mechanism in all cases. One routine

Agreed.

> that can be used is lckpwdf (and ulckpwdf to unlock) if it
> exists. I don't know where it comes from: in glibc, there is
> no documentation on it; on Solaris 2.6, man lckpwdf gives:
> NOTES
> These routines are for internal use only; compatibility
> is not guaranteed.

Still, glibc provides a lckpwdf in <shadow.h>, and the implementation
looks fine. A man page would be nice.

> Shadow-utils uses this pair (or at least should) if it
> available (autoconf test). Current pam_unix also can use
> it (and only) if USE_LCKPWDF defined.

shadow-utils also brings its own implementation of lckpwdf and uses
that (in addition to libpwdb-compatible locking) if HAVE_LCKPWDF is
not defined. In fact, the implementation that pam_unix uses (in all
cases) is taken from shadow-utils. Fortunately, it appears to be
compatible with what we have in glibc (I've done no testing, though).
(Older versions of glibc used flock() rather than fcntl(), according
to the glibc ChangeLog.)

> Well, I see two common locking mechanisms:
>
> lckpwdf way is creating /etc/.pwd.lock file to lock
> both passwd and shadow

It is important that .pwd.lock is also fcntl()-locked, which allows
for stale lock files to be overridden with no extra checks.

> other way used in shadow-utils (if lckpwdf is not
> available?) and pwdb is to create passwd.lck and
> shadow.lck files

shadow-utils uses both kinds of locking at the same time.

This is what can be seen while running vipw from shadow-utils:

$ ls -l /etc/.pwd.lock /etc/passwd.lock
-rw------- 1 root root 0 Aug 27 07:20 /etc/.pwd.lock
-rw------- 1 root root 6 Aug 27 07:20 /etc/passwd.lock

and after exiting vipw we get:

$ ls -l /etc/.pwd.lock /etc/passwd.lock
ls: /etc/passwd.lock: No such file or directory
-rw------- 1 root root 0 Aug 27 07:20 /etc/.pwd.lock

So, the .pwd.lock file is left there, but it is obviously no longer
fcntl()-locked. (I did make sure it is created by the vipw if it
didn't exist.)

> I looked to lckpwdf implementation in glibc -- it is
> pretty cheap (it does not checks for stale lock, but
> this is rather ok for this sort of things I think).

It does the fcntl, and that's enough, -- no explicit checks needed.

> So, I think that pam_pwdb and shadow-utils should be
> patched instead, and all new code should use
> lckpwdf also.

pam_pwdb should probably be patched (or we should simply switch to
using the module you're developing). shadow-utils already uses
lckpwdf as one of the two locking mechanisms.

util-linux should definitely be patched, as it uses a third locking
mechanism.

Signed,
Solar Designer