Re: open()ing a directory without O_DIRECTORY
Christos Zoulas <[email protected]> Sun, 3 Mar 2019 14:41:35 -0500
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
> On Mar 3, 2019, at 2:17 PM, Aymeric Vincent <[email protected]> wrote: > > [email protected] (Christos Zoulas) writes: > >> In article <[email protected]>, >> Aymeric Vincent <[email protected]> wrote: >>> >>> 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... :-/ >> >> Why? The kernel can just zero out the deleted dirents. > > Forgot to mention: "in the current situation". And yes, that's exactly > what I think, probably the alternative is > > - zero out on unlink() so that the data is no longer on the disk > (Everybody seems to have expressed preference for this solution but I > think this requires changing all the affected filesystems) > - zero out in getdents() so that the data cannot be accessed without > accessing the raw device, mimicking the behaviour of unlink for the > data: data still present on disk but not accessible without accessing > the raw device. (This requires forbidding read() and similar on > directories) Well, even if you zero out the new entries as you delete them, you need to have a way to update filesystems that have old unclean directories. Perhaps we can have fsck do it, or even better have way (through fcntl/ioctl/ new syscall/or even abusing open flags) to clean and/or compact an existing directory (which we cannot do right now). I am not opposed to changing O_DIRECTORY to be required to open directories (and overriding globally via sysctl), but that does not fix the underlying issue. christos