From owner-freebsd-hackers Sun Jun 23 16: 9:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hardtime.linuxman.net (hardtime.linuxman.net [66.147.26.65]) by hub.freebsd.org (Postfix) with ESMTP id 3317E37B401 for ; Sun, 23 Jun 2002 16:09:27 -0700 (PDT) Received: from mortis.over-yonder.net (localhost [127.0.0.1]) by hardtime.linuxman.net (8.11.6/8.11.6) with ESMTP id g5NMFJB04634; Sun, 23 Jun 2002 17:15:20 -0500 Received: by mortis.over-yonder.net (Postfix, from userid 100) id 285161F06; Sun, 23 Jun 2002 18:09:24 -0500 (CDT) Date: Sun, 23 Jun 2002 18:09:23 -0500 From: "Matthew D. Fuller" To: Paul Herman Cc: "Geoffrey C. Speicher" , freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623230923.GM81018@over-yonder.net> References: <20020623210636.GK81018@over-yonder.net> <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> User-Agent: Mutt/1.4i-fullermd.1 X-Editor: vi X-OS: FreeBSD 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 OK, this is the end for me today. I'm fairly sure, somehow, it's time to get some sleep ;p On Sun, Jun 23, 2002 at 03:51:46PM -0700 I heard the voice of Paul Herman, and lo! it spake thus: > > 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. No, it means that (with configuration) you can only update them once at a time in each jail. I'm all in favor of adding options, either command line, or pw.conf (or both) to put the lockfile somewhere else; -V ${dir} already makes pw(8) read ${dir}/pw.conf instead of the default /etc/pw.conf, so we're 90% of the way there already. Heck, I wouldn't be too worried about adjusting the lockfile location based on -V automagically. I'm also not opposed to adding an option to not bother with this locking; I already added one to pwd_mkdb(8) (primarily because it's called from libutil's pw_mkdb(3), which is called by vipw(8)... deadlocks suck). I just haven't done either NOW; nor have I yet added options to 'block on the lock and keep trying' (or decided to make blocking the default and have a switch for non-blocking) - this is experimental implementation stage, after all. I don't claim this is perfect for every case; I'm just taking aim at the common case, where it's currently far too easy to accidentally screw yourself in the foot. > 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. Yes, I've seen that. > A: Agreed, this is a problem. However, no system in place will > prevent at any time anyone with the proper credentials from > doing: I was aiming more at: > User A adds user with pw(8) * pw(8) gets together stuff, internally adds user and group * pw(8) builds homedirs, skel files, changes ownership * pw(8) opens and locks master.passwd (and assorted temp files) and starts rewriting - User B adds group % User B's pw(8) (or other) invocation adds group with GID that User A's pw(8) had already assigned and chmod'd for user above * User A's pw(8) either errors out leaving job half done, or adds group with duplicate GID, or (not coded) backs out everything it's done and starts over, or (ditto) backs out everything it's done and errors back to User A, who screams and bitches and dumps User B into the East River after sundown. Similar situations can be thought up. My POV on this is that more than 1 file has to be coordinated here, so why not just make 1 file responsible for the coordination? I don't care THAT much if it's called /var/run/pwd.lock or /etc/passwd.lock or /kernel (I suggest testing the latter on a scratch system). It just seems to me the simplest and least error-prone way of doing it. > 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. Now, mind you; were this a high-traffic subsystem, where one would normally have 2 or 3 or 4 "requests" (changes) outstanding, with a constant stream coming in keeping the queue full, I'd be out there screaming for fine-grained locking of individual pieces of it. But really; how many systems are there (that are using stock passwd and getpw* and pw/pwd_mkdb/etc) that are adding users at even a significant fraction of the speed the system can process them? A coarse lock is easier on the programmer (especially being as we have quickie functions that do the job for them), the admin (easier to see an extra lock file, then a hung process holding a flock()), and pretty much everything else. > Why use lockfiles, when we can lock files? Let's lock files and > keep the snack bar open! :-) We are locking a file :) We're just locking one file for the whole subsystem, so the pieces can be assured of being in sync. So, where's a snack bar with no CVS repository or text editor or diff(1); I need a vacation! -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message