fdopendir (BUG?)

fdopendir (BUG?)

[Jorge Almeida]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

Calling fdopendir with a file descriptor obtained with O_PATH yields a
bad directory  stream descriptor (as it should, if I understood
correctly the documentation of open() re O_PATH). However, the call
doesn't fail (it should fail with EBADF). A subsequent call to readdir
(3) detects the error.

(the problem also occurs with glibc, besides the fact that glibc
requires also _GNU_SOURCE to compile, contradicting  the linux man
page)

Am I  missing something? (Complete test program in attachement, so
that Gmail doesn't crap it.)

Thanks,

Jorge Almeida

[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 792 bytes --]

#define _POSIX_C_SOURCE 200809L
//#define _GNU_SOURCE
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <dirent.h>
#include <errno.h>

/* "somedir" should be an existing subdirectory of the current directory */

int main(int argc, char* argv[]){
		int fd=open("somedir", O_RDONLY|O_PATH|O_DIRECTORY);
//		int fd=open("somedir", O_RDONLY|O_DIRECTORY);
		if(fd == -1){
				fprintf(stderr, "open: %d\n", errno);
				exit(1);
		}
		DIR* dir=fdopendir(fd);
//		DIR* dir=opendir("somedir");
		if(dir == NULL){
				fprintf(stderr, "fdopendir: %d\n", errno);
				exit(1);
		}
		struct dirent* de;
		errno=0;
		de=readdir(dir);
		if(de == NULL && errno){
				fprintf(stderr, "readdir: %d\n", errno);
				exit(1);
		}
}

Re: fdopendir (BUG?)

[Rich Felker]

On Mon, Jan 28, 2019 at 12:37:30PM +0000, Jorge Almeida wrote:
> Calling fdopendir with a file descriptor obtained with O_PATH yields a
> bad directory  stream descriptor (as it should, if I understood
> correctly the documentation of open() re O_PATH). However, the call
> doesn't fail (it should fail with EBADF). A subsequent call to readdir
> (3) detects the error.
> 
> (the problem also occurs with glibc, besides the fact that glibc
> requires also _GNU_SOURCE to compile, contradicting  the linux man
> page)

Indeed, POSIX says "shall fail" if it's not a fd open for reading, so
I think we need to detect this somehow. One obvious way, but it would
require slightly invasive changes I think, is pre-buffering the first
getdents at open time. Easier but slightly more expensive is doing a
fcntl to get the file mode and rejecting O_PATH explicitly.

Rich

Re: fdopendir (BUG?)

[Adhemerval Zanella]

On 28/01/2019 10:37, Jorge Almeida wrote:
> (the problem also occurs with glibc, besides the fact that glibc
> requires also _GNU_SOURCE to compile, contradicting  the linux man
> page)
Because O_PATH is a Linux extension and it guards such definitions
with _GNU_SOURCE. And although man-pages is not the canonical glibc
documentation, it does states that O_PATH is only defined if
_GNU_SOURCE is also defined (man-pages commit 
1135dbe188a48d7fa237396ab371ebf74037c1f6 from 2013-02-13).

Re: fdopendir (BUG?)

[Jorge Almeida]

On Mon, Jan 28, 2019 at 6:54 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 28/01/2019 10:37, Jorge Almeida wrote:
> > (the problem also occurs with glibc, besides the fact that glibc
> > requires also _GNU_SOURCE to compile, contradicting  the linux man
> > page)
> Because O_PATH is a Linux extension and it guards such definitions
> with _GNU_SOURCE. And although man-pages is not the canonical glibc
> documentation, it does states that O_PATH is only defined if
> _GNU_SOURCE is also defined (man-pages commit
> 1135dbe188a48d7fa237396ab371ebf74037c1f6 from 2013-02-13).

My man page for opendir has the date  2017-09-15 ("release  4.16  of
the  Linux  man-pages  project") It says:
   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       fdopendir():
           Since glibc 2.10:
               _POSIX_C_SOURCE >= 200809L
           Before glibc 2.10:
               _GNU_SOURCE

I have glibc-2.27

Re: fdopendir (BUG?)

[Adhemerval Zanella]

On 28/01/2019 17:42, Jorge Almeida wrote:
> On Mon, Jan 28, 2019 at 6:54 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 28/01/2019 10:37, Jorge Almeida wrote:
>>> (the problem also occurs with glibc, besides the fact that glibc
>>> requires also _GNU_SOURCE to compile, contradicting  the linux man
>>> page)
>> Because O_PATH is a Linux extension and it guards such definitions
>> with _GNU_SOURCE. And although man-pages is not the canonical glibc
>> documentation, it does states that O_PATH is only defined if
>> _GNU_SOURCE is also defined (man-pages commit
>> 1135dbe188a48d7fa237396ab371ebf74037c1f6 from 2013-02-13).
> 
> My man page for opendir has the date  2017-09-15 ("release  4.16  of
> the  Linux  man-pages  project") It says:
>    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
> 
>        fdopendir():
>            Since glibc 2.10:
>                _POSIX_C_SOURCE >= 200809L
>            Before glibc 2.10:
>                _GNU_SOURCE
> 
> I have glibc-2.27
> 

This is for *fdopendir* declaration, the *O_PATH* flag is documented by
open.2 and it defines:

---
CONFORMING TO
       open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.

       openat(): POSIX.1-2008.

       The O_DIRECT, O_NOATIME, O_PATH, and O_TMPFILE flags are Linux-specific.  
One must define _GNU_SOURCE to obtain their definitions.
---

Re: fdopendir (BUG?)

[Jorge Almeida]

On Mon, Jan 28, 2019 at 8:31 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>

> > the  Linux  man-pages  project") It says:
> >    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
> >
> >        fdopendir():
> >            Since glibc 2.10:
> >                _POSIX_C_SOURCE >= 200809L
> >            Before glibc 2.10:
> >                _GNU_SOURCE
> >
> > I have glibc-2.27
> >
>
> This is for *fdopendir* declaration, the *O_PATH* flag is documented by
> open.2 and it defines:
>
> ---
> CONFORMING TO
>        open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
>
>        openat(): POSIX.1-2008.
>
>        The O_DIRECT, O_NOATIME, O_PATH, and O_TMPFILE flags are Linux-specific.
> One must define _GNU_SOURCE to obtain their definitions.
> ---

OK, got it. Still, it compiles against musl, even without   _GNU_SOURCE

Re: fdopendir (BUG?)

[Adhemerval Zanella]

On 28/01/2019 19:33, Jorge Almeida wrote:
> On Mon, Jan 28, 2019 at 8:31 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
> 
>>> the  Linux  man-pages  project") It says:
>>>    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>>>
>>>        fdopendir():
>>>            Since glibc 2.10:
>>>                _POSIX_C_SOURCE >= 200809L
>>>            Before glibc 2.10:
>>>                _GNU_SOURCE
>>>
>>> I have glibc-2.27
>>>
>>
>> This is for *fdopendir* declaration, the *O_PATH* flag is documented by
>> open.2 and it defines:
>>
>> ---
>> CONFORMING TO
>>        open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
>>
>>        openat(): POSIX.1-2008.
>>
>>        The O_DIRECT, O_NOATIME, O_PATH, and O_TMPFILE flags are Linux-specific.
>> One must define _GNU_SOURCE to obtain their definitions.
>> ---
> 
> OK, got it. Still, it compiles against musl, even without   _GNU_SOURCE
> 

Because musl defines O_EXEC as O_PATH which I am not entirely sure it is
correct for Linux. As Joseph has noted on glibc BZ#18222 [1] we need 
kernel agreement the kernel will reserve this value and the proper 
semantic it will implement (even if this is similar to O_PATH).

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=18228