Date: Sun, 23 Jun 2002 15:51:46 -0700 (PDT) From: Paul Herman <pherman@frenchfries.net> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: "Geoffrey C. Speicher" <geoff@sea-incorporated.com>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> In-Reply-To: <20020623210636.GK81018@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
> I'm talking about down around line 177 thru (unpatched), where it's
> copying back to the primary file.
> [...]
> which is Very Bad (tm) in that it's not very resilient against
> system crashes. The rename() solution is much safer.
Ah, now I see, thanks. No contention there, we are in total
agreement that this is a Bad Thing, and that rename() is
sufficient.
> No, it's more like closing the snack bar while you clean it,
> rather than closing the first steam tray while cleaning that,
> then the second steam tray, then the third booth on the left
> side, then...
OK, you can change the analogy, but you're still closing the snack
bar, and you turn away customers. Most 24 hour snack bars clean
each table at a time as each one frees up.
Moral of that story: This would mean for pw(8) that I can't update
the system passwords and the passwords in all my jails at the same
time. There is no reason to enforce that policy.
Back to the situation at hand. You make a few points that should
be clarified, I'll summarize them in Q&A format:
Q: rename() is good, but you can't flock() the file in question
and handle it easily, can you?
A: Indeed, you can. flocks() are even preserved across renames.
Consider:
lockf -k foo sleep 60 &
mv foo bar
lockf -t 1 -k bar true
The second lockf will error.
Q: What about other programs not written by us that modify
things?
A: Agreed, this is a problem. However, no system in place will
prevent at any time anyone with the proper credentials from
doing:
echo junk > /etc/master.passwd
At least if the programs in the base agree on a system
(be it flock() or /var/run lock) it will work for the base
system. This doesn't speak for or against any one method.
Yes, a lock on "changes to the auth information" is the only
way to ensure consistency, which is what this is all about,
but HOW to accomplish this issue at hand.
> Commit? How would I do that? :P
Sorry, it wasn't as much directed at you as it was more of a
general plea. Kind of like this one:
Why use lockfiles, when we can lock files? Let's lock files and
keep the snack bar open! :-)
-Paul.
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?20020623150105.T38873-100000>