bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unsafe use of dirfd in fts.c, getcwd.c, glob.c?


From: Paul Eggert
Subject: Re: unsafe use of dirfd in fts.c, getcwd.c, glob.c?
Date: Sun, 12 Sep 2010 23:54:11 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7

On 09/12/2010 10:25 PM, Jim Meyering wrote:

> but fts.c uses dirfd like this:
>  ....
> and while that code may call set_cloexec_flag on a negative DIR_FD
> (upon failed "dup" call -- I'll fix that, mainly for consistency),
> I don't see how it assumes dirfd never returns -1.

You're right; I didn't read the code carefully enough; sorry about
that.  So in gnulib it's only getcwd.c and glob.c that are making that
assumption.

> The POSIX wording allowing dirfd to fail on a valid stream is far older
> than the *at functions, for which dirfd can now be essential.  Given this
> relatively new constraint, the odds of any new, useful system providing
> a stream interface without a backing file descriptor are nil.

I am hoping you're right (it does match my experience and
expectation).  If so, we don't need to "fix" getcwd.c and glob.c,
and we can simplify GNU tar along the lines you suggested.
But also, can't we simplify fts.c slightly, as follows?

--- old/fts.c   2010-09-12 23:32:51.672822000 -0700
+++ new/fts.c   2010-09-12 23:48:51.004174000 -0700
@@ -1302,7 +1302,7 @@ fts_build (register FTS *sp, int type)
          */
         if (nlinks || type == BREAD) {
                 int dir_fd = dirfd(dirp);
-                if (ISSET(FTS_CWDFD) && 0 <= dir_fd)
+                if (ISSET(FTS_CWDFD))
                   {
                     dir_fd = dup (dir_fd);
                     if (0 <= dir_fd)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]