From owner-freebsd-hackers Sun Jun 23 15:53:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by hub.freebsd.org (Postfix) with ESMTP id 4169037B400 for ; Sun, 23 Jun 2002 15:53:12 -0700 (PDT) Received: from mammoth.eat.frenchfries.net (da001d0242.lax-ca.osd.concentric.net [64.0.144.243]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g5NMT2O29467 for ; Sun, 23 Jun 2002 15:29:05 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 3517F57C7; Sun, 23 Jun 2002 15:51:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 2F9625183; Sun, 23 Jun 2002 15:51:46 -0700 (PDT) Date: Sun, 23 Jun 2002 15:51:46 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: "Matthew D. Fuller" Cc: "Geoffrey C. Speicher" , Subject: Re: bug in pw, -STABLE [patch] In-Reply-To: <20020623210636.GK81018@over-yonder.net> Message-ID: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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