On Sun, Jun 23, 2002 at 05:14:58PM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
Clearly, at the root of our disagreement is what we both perceive
the problem to be.
Oh, certainly; that's what makes it fun :)
I don't see problems in the current implementation, aside
On Sun, Jun 23, 2002 at 05:07:40PM -0700 I heard the voice of
Terry Lambert, and lo! it spake thus:
The problem with your proposed patch is that it breaks the
ability to allow authentication against the database while
it is undergoing modification, which may be a prolonged period.
Would it?
On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
So we either need to have a compelling solution or get a
committer to step in and make up our minds for us.
I think the best thing to do is file a PR for this.
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
On Mon, 24 Jun 2002, Paul Herman wrote:
On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
So we either need to have a compelling solution or get a
committer to step in and make up our minds for us.
I think the best thing to do is file a PR for this.
With or without a patch?
Geoff
To
Matthew D. Fuller wrote:
Terry Lambert, and lo! it spake thus:
The problem with your proposed patch is that it breaks the
ability to allow authentication against the database while
it is undergoing modification, which may be a prolonged period.
Would it?
For starters, this locks
On Mon, 24 Jun 2002, Paul Herman wrote:
On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
So we either need to have a compelling solution or get a
committer to step in and make up our minds for us.
I think the best thing to do is file a PR for this.
More than one person has already
On Mon, Jun 24, 2002 at 09:56:31AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
On Mon, 24 Jun 2002, Geoffrey C. Speicher wrote:
So we either need to have a compelling solution or get a
committer to step in and make up our minds for us.
I think the best thing to do is
[ Moved to -hackers since this isn't really a STABLE-specific issue, but
rather a general thing. Bcc's to -stable for continuity's sake. ]
This discussion has gone on, on and off, for months now, so I'm going to
recap a bit. For the people in it, we've mostly paged out the details by
now, and
On Sun, Jun 23, 2002 at 11:17:35AM -0400 I heard the voice of
Geoffrey C. Speicher, and lo! it spake thus:
5-minute window. Still unliklely, but not quite as unlikely as the
non-daemon scenario.
And it all goes out when window when kern.randompid=1, so it's kinda
moot.
Looks good from
[ pulled over to -hackers as well ]
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
On Sun, Jun 23, 2002 at 09:00:52AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
On Sun, 23 Jun 2002, Geoffrey C. Speicher wrote:
How so? I'm not suggesting unlink(2)ing
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
On Sun, Jun 23, 2002 at 09:59:10AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
I can't imagine it would be too extensive of a rewrite. The temp
file code could be kept, and in fileupd.c:fileupdate() instead of
And here's a run at Stage 2. This adapts a subset of programs to use the
pid_*() locking supplied. The attached patch updates: pwd.h, libutil
(libutil.h and pw_util.c), chpass (chpass.c), pw (pw.c), pwd_mkdb
(Makefile, pwd_mkdb.8, pwd_mkdb.c), vipw (vipw.c). This does NOT include
passwd(1),
On Sun, Jun 23, 2002 at 11:32:54AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
In fact, if you look at fileupdate(), you see that it already gains
an exclusive lock on the temp file, but not the original
/etc/master.passwd (if you will.) I think this is a bug, because
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
On Sun, Jun 23, 2002 at 11:32:54AM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
In fact, if you look at fileupdate(), you see that it already gains
an exclusive lock on the temp file, but not the original
On Sun, Jun 23, 2002 at 01:19:02PM -0700 I heard the voice of
Paul Herman, and lo! it spake thus:
I think you might have your infp confused with your outfp. It's
not writing to the original live file, it's just writing the new
temp file. That part of the code is OK.
I'm talking about down
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,
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
Paul Herman wrote:
Fine, then lock them both, and use rename(). Patch attached.
In fact, if you look at fileupdate(), you see that it already gains
an exclusive lock on the temp file, but not the original
/etc/master.passwd (if you will.) I think this is a bug, because
the original is
On Sun, 23 Jun 2002, Matthew D. Fuller wrote:
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.
...and have the screw (or bullet) delivered as precisely, quickly
and efficiently
Matthew D. Fuller writes:
...
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.
Time to implement hierarchic lock.
On Sun, 23 Jun 2002, Paul Herman wrote:
You see the problem as a deficiency in the implementation itself,
and wish to protect the user from shooting themselves in the foot.
Not only do I think that's impossible[*], I choose to fight for my
right to shoot myself in the foot as quickly and
[I'm bringing the discussion back to -hackers, since it was omitted in
your original reply, Paul. To get everyone up to speed, Paul suggested
that calling unlink() _before_ close() should solve the race condition
mentioned in my original message. However, that still leads to
corruption, and
On Sat, 18 May 2002, Geoffrey C. Speicher wrote:
The file isn't actually unlinked until p1 closes the fd
Hmm. Rechecking the man page for unlink(2) I see that I worded
the above incorrectly. The file is unlinked when you unlink(),
but not actually removed until close().
Well, unlink
23 matches
Mail list logo
