Date: Tue, 8 Aug 2000 09:00:03 -0700 (PDT) From: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3) Message-ID: <200008081600.JAA39350@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/20445; it has been noted by GNATS.
From: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu>,
freebsd-gnats-submit@freebsd.org
Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3)
Date: Tue, 08 Aug 2000 08:53:56 -0700
In looking at the OpeBSD 1.1->1.2 diff and the 1.2->1.3 diffs for dirs.c,
it looks like that mkstemp(3) was applied in 1.1->1.2 in extractdirs(), but
that setdirmodes() still recreated the value of modefile on its own instead
of using the value of modefile created by mkstemp(3) back in extractdirs().
OpenBSD, src/sbin/dirs.c, r1.2
setdirmodes(flags)
int flags;
{
FILE *mf;
struct modeinfo node;
struct entry *ep;
char *cp;
vprintf(stdout, "Set directory mode, owner, and times.\n");
(void) sprintf(modefile, "%s/rstmode%d", _PATH_TMP, dumpdate);
mf = fopen(modefile, "r");
if (mf == NULL) {
fprintf(stderr, "fopen: %s\n", strerror(errno));
fprintf(stderr, "cannot open mode file %s\n", modefile);
fprintf(stderr, "directory mode, owner, and times not set\n");
return;
}
...
Since extractdirs() in 1.2 used mkstemp(3) to create unique filenames,
setdirmodes() would fail on opening the file since it expected a filename
of the form "/tmp/rstmodeDECIMAL", instead of "/tmp/rstmodeDECIMAL-MKSTEMP"
which extractdirs created via mkstemp(3).
the 1.2->1.3 patch fixed this by having restore use "/tmp/rstmodeDECIMAL"
for the "R" and "r" cases in both extractdirs() and setdirmodes() so that
they were using the same filename. It is not clear to me why setdirmodes()
was not modified to just rely on the mkstemp(3) value of modefile used
back in extractdirs() instead of the special casing of "R" and "r" or why
the value of dirfile is not created via mkstemp(3) in all cases for that
matter. I guess a better question should be "why did setdirmodes() ever
try to recreate the value of modefile on its own?" None of the other
functions that rely on dirfile, for instance, ever try to recreate that
value from scratch, and instead rely on extractdirs() to do its thing
to the value dirfile.
In any case, it seems like a good idea to talk to the author of the original
patch for this since we all seem to have a bunch of questions about this now
Cheers,
Jon
Sheldon Hearn <sheldonh@uunet.co.za> writes:
: On Mon, 07 Aug 2000 09:37:22 MST, Jon Masami Kuroda wrote:
:
: > This "bug" should not have any security impact if I understand open(2)
: > and the "O_EXCL" flag correctly. It is, so far, just a productivity
: > annoyance.
:
: While that's certainly the way it looks to me, I'm very uncomfortable
: with proceding without finding out _why_ OpenBSD's rev 1.3 was required.
: Essentially, your patch proposes that we revert NetBSD's rev 1.3. The
: CVS log for that delta implies that the patch you propose will somehow
: break the -r and -R options.
:
: I'm not sure whether <lukem@supp.cpr.itg.telecom.com.au> is still a
: deliverable address. Perhaps you could chat to Theo and ask him why the
: revision was introduced in the first place?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008081600.JAA39350>