lkml.org 
[lkml]   [2000]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.083 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site