Re: open()ing a directory without O_DIRECTORY

[Aymeric Vincent <aymericvincent%free.fr@localhost>]

matthew green <mrg%eterna.com.au@localhost> writes:

> i don't see the security issue here.

Here is an instance of the example I gave:

localhost$ mkdir foo
localhost$ cd foo
localhost$ touch secretfile1 secretfile2
localhost$ rm secretfile1 secretfile2
localhost$ # Give access to directory "foo" to someone else here
localhost$ hexdump -C .
00000000  b6 d4 76 00 0c 00 04 01  2e 00 00 00 00 a6 62 00  |..v...........b.|
00000010  f4 01 04 02 2e 2e 00 00  fd d7 76 00 14 00 08 0b  |..........v.....|
00000020  73 65 63 72 65 74 66 69  6c 65 31 00 fe d7 76 00  |secretfile1...v.|
00000030  d4 01 08 0b 73 65 63 72  65 74 66 69 6c 65 32 00  |....secretfile2.|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
localhost$ 

> i can't open a directory and read it if i don't have read perms
> on it.  this stops ls(1) etc from working.  i can't see any leak
> here that depends upon being able to read(2) a directory.  you
> can get the same data from readdir() or read(), only if you can
> actually read the directory itself.

Well, maybe getdents() needs to be patched to avoid a leak, but that's
perfectly doable if it's not already done.

There is no trivial way to get rid of this no longer valid contents,
since for good reason you can't write to a directory as a file. You have
to re-create it (not always possible due to permissions) or create long
entries until your data disappears... :-/

> is there some corner case i'm missing?  please provide an actual
> example you think leaks info.

See above.

> i may be sold on the usability point, because i rarely want to
> actually grep or look inside a directory entry as-is, but i
> think that belongs on a different list.

Heh, fine. :-)

 Aymeric