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