Messages in this thread | | | Date | Thu, 23 Sep 1999 18:31:45 +0200 | From | Jamie Lokier <> | Subject | Re: Why is chmod(2)? |
| |
Mitchell Blank Jr wrote: > I am *very* wary of this idea. A year or two ago there was a big hole > in the BSD's because you could do: > i = open("foo", 0) > without any access to "foo" and get a filedescriptor without read or > write access. The problem is that many devices will implicitly allow > any ioctl() done to them (on the theory that you must have had permission > to open the device). You're potentially opening the same sorts of > bugs in linux.
One imagines that a file opened O_NONE would never, *ever* call device functions. It would be stopped at the VFS layer.
> Second, file descriptors are currently analagous to capabilities (the > academic use of the word, *not* the linux use of the word) in that they > are indications of security that can be passed among processes with > differing credentials (either across a set[ug]id execve or by passing > them across a socket) Allowing any process to get a filedescriptor > without needing read or write permission undermines these basic > semantics.
Not if the only things that can be done with the file descriptor are *exactly* the same ones that can be done with a name. No more.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |