Messages in this thread | | | Date | Fri, 24 Mar 2000 14:21:07 +0100 | From | Jamie Lokier <> | Subject | Re: fcntl(2) and other file systems like XFS |
| |
Mitchell Blank Jr wrote: > > On a file with permission 400 or 200 or 000: > > > > open("f", 0x4) = -1 EACCES (Permission denied) > > > > Oh dear, you need to read _and_ write permission to open this file with > > mode O_NONE. And then you can't read or write it :-) > > Yes, that's very important. There was a long-standing security bug in > *BSD's where you could open("/dev/whatever", 0) with no permission on > the inode and then do ioctl()s at it. Under linux, you're only allowed > to create these special file handles if you have complete permission to > open the file. It's counter-intuitive, but correct.
I think correct is stretching the definition of correct to include BSD-compatible. Why is read _or_ write access not enough for non-directories, and execute access not enough for directories?
At least for the uses proposed, opening with no permission isn't required. So we don't have to consider that. (Though the only problem I have thought of open-without-permission is where you open a directory handle that you have no permission on, and that prevents unmounting the fs rooted at that directory. Unlikely but possible.)
After such an open, fstat(), fchown() etc. should be allowed (as they are). Opening a directory should be permitted, and chdir() should then be permitted if the directory is executable. read/write/ioctl should not be permitted, but fcntl should be. Devices should not actually open the device (as that has side effects) but they should get a handle permitting fstat() etc. And as a special exception, ioctls interpreted by the fs for setting/clearing fs-specific flags should be permitted. In cases of ioctl number collision with devices, this guarantees you do the fs-specific ioctl and not the device ioctl.
It is possible to arrange for fake handles if you want a clean guarantee that this is watertight.
-- 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/
| |