re: open()ing a directory without O_DIRECTORY
matthew green <[email protected]> Sun, 03 Mar 2019 01:02:41 +1100
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
> on BSD, it has historically been possible to open() and read() a > directory. While this is fun, it also leaks part of the history of the > contents of the directory. E.g. you give rights to a directory after > clearing its contents, and you actually give access to many filenames > present in that directory when it had more restrictive rights. > > I fail to see any fair use of this behaviour (except for pedagogical > purposes), and would like to suggest that we return EISDIR when a > directory if open()ed without O_DIRECTORY, and make sure that even then > they can't be read()/mmap()ed/... directly (didn't check if it's the > case now). > > Does anyone see a good reason to keep the historical behaviour? FWIW, I > think at least OpenBSD dropped that. i don't see the security issue here. 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. is there some corner case i'm missing? please provide an actual example you think leaks info. 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. .mrg.