Re: open()ing a directory without O_DIRECTORY
Aymeric Vincent <[email protected]> Sat, 02 Mar 2019 16:09:26 +0100
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
Christos Zoulas <[email protected]> writes: > No I don't need to do anything special I can open the device file as root. You will still be able to do that for directories even if a normal user can't read() a directory anymore. > And this is not the reason that > directory operations moved to the kernel. It is the same reason that > mkdir(2) became a system call: atomicity/safety. The reason is that otherwise you could create cycles in the tree structure, point to inexistant inodes, and so on. Coherency has to be maintained in the metadata. >> That's easily fixed in getdents() if it's not already the case. > > getdents(2) has nothing to do with open(2). It takes an fd. Well, in order for my suggestion to work, read() would have to fail on a fd opened with O_DIRECTORY, and getdents() would become the only checkpoint for this data. > You are worried then about data disclosure, and instead of fixing it at > the place where it happens (the filesystem code should zero the > dirent data when it removes the last link to one), you just want to hide it. Agreed. The same as when you unlink a file, it doesn't destroy its contents, just renders it inaccessible to normal users. My approach forbids disclosure to standard users in a filesystem independent way, whereas cleaning upon unlink() requires support in each filesystem. Of course I'm not opposed to the latter either. Aymeric