Re: gnu tar 1.19 requires open() with O_DIRECTORY?

2008-02-20 Thread John E. Malmberg
Bruno Haible wrote: John E. Malmberg wrote: The open() would have to open or dup a file descriptor to the /dev/null device to reserve a unique file descriptor, and then something needs to map that file descriptor back to the pointer to the *DIR structure. Do you need a pointer to the DIR st

Re: gnu tar 1.19 requires open() with O_DIRECTORY?

2008-02-20 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John E. Malmberg on 2/20/2008 6:23 PM: |> Tar is using O_DIRECTORY to close a security hole, and not to directly |> read the directory contents. And POSIX requires that a directory be |> openable read-only, even though reads on such a fd

Re: gnu tar 1.19 requires open() with O_DIRECTORY?

2008-02-20 Thread Bruno Haible
John E. Malmberg wrote: > I could not find that Posix specification on the web, not even a draft. POSIX:2001 is the same as the "OpenGroup Base Specification Issue 6" and also known as "SUSv3". You find it on the web at http://www.opengroup.org/susv3/ > The open() would have to open or dup a f

Re: gnu tar 1.19 requires open() with O_DIRECTORY?

2008-02-20 Thread John E. Malmberg
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to John E. Malmberg on 2/18/2008 8:46 PM: | I have run into a problem: GNU TAR now requires that the open() call | support O_DIRECTORY. Tar is using O_DIRECTORY to close a security hole, and not to directly read the direc

Re: [PATCH] Correct typo in comment in fts.c

2008-02-20 Thread Martin Buchholz
Although I know very little about fts itself, I have all the pre-requisites to be able to debug the problem in fts on Solaris, except for time. I already have a number of free-software mini-projects that are on the back-burner for lack of time to hack on them. Martin > "J" == James Youngman

Re: [PATCH] Correct typo in comment in fts.c

2008-02-20 Thread James Youngman
On Feb 20, 2008 12:12 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > This reminds me of the long-planned fork, e.g., s/fts_*/gfts_*/, > (all public symbols) in which I create new files named gfts.[ch]. Then, > someday, I can propose adding it to glibc. Remember, proposing the > addition with new

Re: [PATCH] Correct typo in comment in fts.c

2008-02-20 Thread Jim Meyering
James Youngman <[EMAIL PROTECTED]> wrote: > 2008-02-20 Martin Buchholz <[EMAIL PROTECTED]> (trivial change) > > * lib/fts.c (fts_build): Typo correction to comment. Thanks! Applied and pushed. This reminds me of the long-planned fork, e.g., s/fts_*/gfts_*/, (all public symbols) in which I

[PATCH] Correct typo in comment in fts.c

2008-02-20 Thread James Youngman
2008-02-20 Martin Buchholz <[EMAIL PROTECTED]> (trivial change) * lib/fts.c (fts_build): Typo correction to comment. --- lib/fts.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/fts.c b/lib/fts.c index ceb8935..cb6f564 100644 --- a/lib/fts.c +++ b/lib/fts.c