Date: Sun, 23 Jun 2002 11:17:35 -0400 (EDT) From: "Geoffrey C. Speicher" <geoff@sea-incorporated.com> To: "Matthew D. Fuller" <fullermd@over-yonder.net> Cc: freebsd-hackers@freebsd.org, Matt Simerson <freebsd@blockads.com>, Paul Herman <pherman@frenchfries.net>, Oliver Fromme <olli@secnetix.de> Subject: Re: Locking the passwd subsystem (was Re: bug in pw, -STABLE [patch]) Message-ID: <20020623105835.E29860-300000@sea-incorporated.com> In-Reply-To: <20020623135441.GC81018@over-yonder.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
> Well, a daemon would have a BETTER chance, though nowhere near a
> guarantee. The theory being that the daemon would check every so often
> (5 minutes sounds good to me), whereas with the library, you potentially
> could not check for days, depending on how often you run pw(8). Even on
> a heavily used system, 5 minutes wouldn't likely be enough to reuse a
> PID, unless you had random PID assignment or some such.
Right, for programs like pw(8), the daemon should definitely suffice for
all practical purposes. For daemons, it's another story. You don't
necessarily have to wrap around the pid list inside of those 5 minutes.
If the original program runs for a long time (which is likely for
daemons), then the pid list could wrap around while it is still running.
Then it is possible that it dies and its pid gets reuser within that
5-minute window. Still unliklely, but not quite as unlikely as the
non-daemon scenario.
> > > Now, this is a problem. There's a race condition here. It's a very
> > > small window, to be sure, but I'm not quite sure how to close it. After
> >
> > I think you must've figured it out judging by your post that just came
> > through as I was writing that previous paragraph. :)
>
> I think so. See comments in the code.
I think so too. I guess we need those flock-style locks after all.
> Code is reasonably well commented. Manpage included. Shaken, not
> stirred. Slippery when wet. This has gone through a compile test, but
> hasn't been live-tested.
Looks good from here. I've attached some minor patches (also relative to
src/) to pid_util.{3,c}. The first corrects some minor typos in the man
page and the second is to make pid_begin() work as advertised when read()
fails (set errno and return -1 rather than return errno).
(I haven't tested any of this yet either.)
You da man.
Geoff
[-- Attachment #2 --]
--- lib/libutil/pid_util.3.orig Sun Jun 23 10:31:39 2002
+++ lib/libutil/pid_util.3 Sun Jun 23 10:35:22 2002
@@ -53,7 +53,7 @@
still exists.
If the process is still alive,
.Fn pid_begin
-will block and continue to try aquiring the lock indefinately, unless
+will block and continue to try aquiring the lock indefinitely, unless
.Dv PID_NOBLOCK
is set in the
.Fa flags ,
@@ -63,7 +63,7 @@
will put its own process ID in the file and continue on its merry way.
.Pp
.Fn pid_end
-removed the file referenced by
+removes the file referenced by
.Fa pidfile .
Note that there is currently no protection afforded here that the process
calling
@@ -86,9 +86,9 @@
The operation was cancelled due to internal error.
.It Bq Er EWOULDBLOCK
The file is already locked by a still-live process and
-.Fa mode
+.Fa flags
includes
-.Dv PID_NOLOCK .
+.Dv PID_NOBLOCK .
.El
.Pp
The
[-- Attachment #3 --]
--- lib/libutil/pid_util.c.orig Sun Jun 23 10:36:34 2002
+++ lib/libutil/pid_util.c Sun Jun 23 10:54:58 2002
@@ -92,7 +92,8 @@
{
holding==errno;
close(lockfd);
- return(holding);
+ errno=holding;
+ return(-1);
}
masterpid = (pid_t) atoi(readpid);
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020623105835.E29860-300000>