Date: Mon, 24 Jun 2002 13:29:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: Paul Herman <pherman@frenchfries.net>, "Geoffrey C. Speicher" <geoff@sea-incorporated.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <3D178124.192785D1@mindspring.com> References: <20020623111412.V38509-100000@mammoth.eat.frenchfries.net> <3D1662CC.FE6F6D49@mindspring.com> <20020624124039.GB59373@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Matthew D. Fuller" wrote: > Terry Lambert, and lo! it spake thus: > > > > The problem with your proposed patch is that it breaks the > > ability to allow authentication against the database while > > it is undergoing modification, which may be a prolonged period. > > Would it? > > For starters, this locks master.passwd, not spwd.db, so any well-behaved > program that used getpw*() like a good little monkey wouldn't even notice > it. In fact, with Paul's change and the rename() alteration, it'd be > BETTER for programs that tried to parse master.passwd, because as it > currently stands, there are times when it's incomplete (because of the > line-by-line copy, which caused us both a few moments of illness when we > noticed it). Whatever locking protocol you come up with needs to be partcipated in by everyone. Historically, passwd file manipulations have used link count locking. The real issue here is that there are a number of incremental file update utilities for managmenet of very large installations, and a large number of historical programs from places like comp.unix.sources that use file locks, rather than advisory range locks. Any locking protocol using advisory locking must lock out readers while there are writers. What you are really locking (or should be) is directory entries here, which means using the same exclusion space for the locking as you use for the update operation, which is a lock on the parent directory (e.g. as is used internally to the FS rename operation). --- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D178124.192785D1>