Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!portc01.blue.aol.com!portc02.blue.aol.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!su-news-hub1.bbnplanet.com!arclight.uoregon.edu!enews.sgi.com!news.sgi.com!news1.best.com!nntp1.best.com!not-for-mail
From: dillon@flea.best.net (Matt Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Locking master.passwd correctly
Date: 26 Dec 1996 16:41:51 -0800
Organization: BEST Internet Communications, Inc.
Lines: 51
Message-ID: <59v60f$rf2@flea.best.net>
References: <59sro8$l1a@atlas.jcpenney.com>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:33284
:In article <59sro8$l1a@atlas.jcpenney.com>,
:drown <drown@chaos.taylored.com> wrote:
:>Hi folks,
:>
:>I've had some weird problems lately with chfn stomping over my account
:>creation software. It seems that chfn doesn't "see" my lock on the
:>master.passwd file sometimes, even though at other times it does. It seems
:>to be a race condition. Here's the relivant perl code for locking the
:>password file:
:>
:>open(MPW, "</etc/master.passwd") || die "cant locate $masterpw?!?!\n";
:>if (!flock(MPW, 6)) {
:> close(MPW);
:> while(1) {
:> open(MPW, "</etc/master.passwd");
:> if (flock(MPW, 6)) { # Got it
:> last;
:> }
:> close(MPW);
:> sleep(5);
:> }
:>}
:>
:>Seems like it should work. The strange thing is that it usually _does_ work,
:>it's just that every so often a user edits their info via chfn and boom,
:>problems. I've confirmed this by patching pwd_mkdb to log when it's called.
:>
:>Any ideas what could be causing this? Am I locking the file incorrectly?
:>
:>Thanks!
:>
:>drown@chaos.taylored.com
There is a race condition whereby one program obtains a lock on the
password file and another hangs waiting for it. If the first
program intends to rename() a temporary file over the password file
as it's 'final' step, the second problem will then obtain a lock
on a now-unlinked file rather then a lock on the new password
file.
There is another race condition with a smaller window in
pw_lock() itself (/usr/src/usr.sbin/vipw/pw_util.c) whereby
third party code may rename over a locked password file between
pw_lock()'s open() call and it's flock() call. chpass/chfn/etc...
call pw_lock().
Hmm.. I'll submit a bug report.
-Matt