Re: open()ing a directory without O_DIRECTORY

[Christos Zoulas <christos%zoulas.com@localhost>]

> On Mar 2, 2019, at 9:53 AM, Aymeric Vincent <aymericvincent%free.fr@localhost> wrote:
> 
> christos%astron.com@localhost (Christos Zoulas) writes:
> 
>> The current behavior is useful because I don't have to modify
>> hexdump, od, etc. or write a special program to look at the contents
>> of a directory.
> 
> But you do in order to look at the superblock. Why is that? And why
> can't you write to a directory as a file? I think it's because both the
> superblock and directory entries belong to what is called "metadata" in
> a filesystem, and as such they need cooking before being served to
> userland.

No I don't need to do anything special I can open the device file as root.
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.

> 
> I also found it cute that directories are seen as files in BSD, but I
> now think it's time to move on because I can't think of a useful use for
> it and it has drawbacks.
> 
>> It is not a security issue, because you can still
>> do it with O_DIRECTORY (you still have the data disclosure).
> 
> 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.

> 
>> It is historical behavior as you say, so why break it?
> 
> I gave an example and instanciated it. You provided no example of use,
> although that's what I was asking for.
> 
>> What's next, create O_DEVICE to open devices, so people accidentally
>> don't mess up their terminals when they cat them?
> 
> Obviously, that's not at all the problem I mentioned nor the direction
> I'm suggesting.
> 

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.

christos