[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnu tar 1.19 requires open() with O_DIRECTORY?
From: |
Eric Blake |
Subject: |
Re: gnu tar 1.19 requires open() with O_DIRECTORY? |
Date: |
Wed, 20 Feb 2008 18:59:19 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 |
-----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 are allowed to fail.
|
| I could not find that Posix specification on the web, not even a draft.
Then you weren't looking in the right place. POSIX 2001 (with TC
amendments to 2004) is available at no cost by joining the Austin Group
(http://www.opengroup.org/austin/). And while the current version does
not describe O_DIRECTORY, it DOES talk about the need to open a directory:
http://www.opengroup.org/onlinepubs/009695399/functions/read.html.
Joining the Austin Group is also a prerequisite for viewing the draft of
POSIX 200x (the review period of draft 4 ends today); it is the 200x draft
that is standardizing O_DIRECTORY as a requirement rather than an optional
extension.
Hmm, while we're at it, the POSIX draft is proposing to add the O_CLOEXEC
flag (to close the security hole of fcntl(open(...),F_SETFD,FD_CLOEXEC)
not being atomic in a multi-threaded app, possibly leaking the fd to a
child app). But gnulib doesn't yet provide a (non-atomic) alternative to
this, nor set O_CLOEXEC to 0 on systems that lack it.
|
| So I can submit a bug report, but I doubt that a fix would show up
| anytime soon, or in older versions.
It is a bug - POSIX requires open("dir",O_RDONLY) to succeed, but
open("dir",O_WRONLY) to fail with EISDIR. However, the file descriptor
thus created is allowed to fail with EISDIR when passed to read().
|
| 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.
|
| Now how to implement this in a way that will work with the rest of the
| wrappers?
It may be worth examining the existing gnulib implementation of an open()
wrapper in fchdir.c, which does just that (mingw can correctly open a
directory, but cannot then tie that fd to a DIR* via fdopendir). VMS is
not a very popular porting platform, so I'm afraid you'll have to do most
of the work, but I also think that gnulib already has most of the hooks in
place.
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHvNr284KuGfSFAYARAm8nAKCGbzPTigBHSaP47D2q+L30MgQrOACZAePH
HN9Zis8oVmDwHwnoJ55o0zA=
=8DwF
-----END PGP SIGNATURE-----
Re: gnu tar 1.19 requires open() with O_DIRECTORY?, James Youngman, 2008/02/21