O_RDONLY

[Barret Rhoden]

This has come up a few times, and it'll probably come up again. You
know how O_RDONLY is actually the value 0:

#define O_RDONLY 0x00 /* Open read-only */

That's getting to be a pain for me. I might need to have FDs that have
no permissions. Say you wanted to do an open or something but not be
able to read or write the FD. How would you express it?

Since we control the OS and runtime, I'm planning on changing O_RDONLY
to something nonzero. That'll require (or at least enable) a few
changes in the kernel where we had to special case O_RDONLY since it
was known to be 0.

As a bigger issue, is anyone aware of issues with making this change?
>From looking around:

http://pubs.opengroup.org/onlinepubs/009695399/functions/open.html

In historical implementations the value of O_RDONLY is zero.
Because of that, it is not possible to detect the presence of
O_RDONLY and another option. Future implementations should
encode O_RDONLY and O_WRONLY as bit flags so that:

O_RDONLY | O_WRONLY == O_RDWR

So I think we're on solid ground here.

Anyway, if anyone has any reasons to not do this, let me know.

Barret

[Dan Cross]

It sounds reasonable. I'm curious why you need FDs with no permission? Semantically, what does that mean?

[ron minnich]

Just guessing: fds with no permission are a way to implement walk.

We'll see all kinds of trouble with this but it's the right move.

ron

[Barret Rhoden]

On 2015-09-02 at 12:41 Dan Cross <cro...@gmail.com> wrote:
> It sounds reasonable. I'm curious why you need FDs with no permission?
> Semantically, what does that mean?

I'm looking into making a "walk" syscall. Right now, I have a
half-baked version on my origin/net branch.

The idea is that you walk to, but do not fully open, a file. You could
then use this "walked FD" for various things, such as a starting point
for an openat() call. Ron mentioned in the past that it'd be a good
thing to allow openat() calls from a file where you don't have
permission to actually access the file. You're just naming a part of
the namespace, after all.

So on the surface, sys_walk is basically a namec() call, just like an
open, but the FD you get back has no permissions. Hence the lack of
O_RDONLY.

The reason this has come up is that I'd like to walk to, but not open,
the "listen" file in #I. And then put an FD tap on it. If you
actually open something like /net/tcp/0/listen, the call blocks and you
get an FD for the new conversation. I just want a reference to
"listen", not the full open. This sounded a lot like sys_walk.

Incidentally, I think sys_walk is so similar to open that I'd make it
O_WALKONLY. I originally made it a standalone call, but the more I
work on it, the less special casing it gets. You can check out what I
have currently at:
963c9c8b4a90 ("Add a syscall to walk to a name (XCC)")

But that's busted. I actually need to call a device operation (like
open) so the device has a chance to grab a refcnt on the file
(conversation, in the case of #I). So it's even more like open, just
without any permissions.

A side question is whether or not a WALKONLY should mean no
permission checks or not. I'm leaning towards saying WALKONLY is just
a flag to the device, with full permission checks. And if someone
wants to do a WALKONLY with no permissions (for the openat where you
can't actually use the FD for anything other than a reference to a
name), then that's a separate thing (still requiring O_RDONLY != 0).

Barret