Date: Sun, 23 Jun 2002 18:09:23 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Paul Herman <pherman@frenchfries.net> Cc: "Geoffrey C. Speicher" <geoff@sea-incorporated.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: bug in pw, -STABLE [patch] Message-ID: <20020623230923.GM81018@over-yonder.net> In-Reply-To: <20020623150105.T38873-100000@mammoth.eat.frenchfries.net> References: <20020623210636.GK81018@over-yonder.net> <20020623150105.T38873-100000@mammoth.eat.frenchfries.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020623230923.GM81018>