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

Re: password file locking

Solar Designer wrote:
> Hi,
> 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).
> Only #1 and #4 use compatible locking.
> 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.
> Signed,
> Solar Designer

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.

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.

Well, I see two common locking mechanisms:

  lckpwdf way is creating /etc/.pwd.lock file to lock
  both passwd and shadow

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

I don't know what of them is a preferred way from
robustness/etc point of view (last seemed to be not
very good but still), but I think that from compatibility
point of view (that original post was about) lckpwdf
way should be the best, since this routine can be implemented
in other systems also but with different methods.
And this way, manual pages will be consistent also,
simple by _not_ mentioning of how locking done, but
giving a link to lckpwdf(3) (to be written for linux).

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

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



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