[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: password file locking

> > 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

> > 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


> 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:
>    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

Solar Designer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []