From owner-freebsd-bugs Tue Aug 8 9: 0: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id D95F937B539 for ; Tue, 8 Aug 2000 09:00:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id JAA39350; Tue, 8 Aug 2000 09:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 8 Aug 2000 09:00:03 -0700 (PDT) Message-Id: <200008081600.JAA39350@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jon Masami Kuroda Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3) Reply-To: Jon Masami Kuroda Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20445; it has been noted by GNATS. From: Jon Masami Kuroda To: Sheldon Hearn Cc: Jon Masami Kuroda , 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 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 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