Re: bug in blkdev <-> VFS interaction. (oops) (fwd)

From: Alexander Viro (viro@math.psu.edu)
Date: Sat Sep 16 2000 - 12:41:39 EST


On Sat, 16 Sep 2000, Alain Knaff wrote:

> >Probably the clean solution would be to add a character device per
> >controller (/dev/fdc), turning eject /dev/fd0 into
> >% echo eject 0 > /dev/fdc0
>
> Why do that for floppies, when we still eject CD-Roms, Zips, "the
> old-fashioned way" with ioctls?

You know, I have nothing against having it that way for CDs and Zips.
And you have an interesting idea of old-fashioned - I'ld say that
echo(1) was in place way before ioctl(2)...

> >etc. Then access control is done via permissions of /dev/fdc* - no need
> >to make the driver aware of VFS guts, layout of struct inode, etc.
>
> Or, maybe you could just add a "safe" permission call to the VFS API
> which wouldn't "blow up in your face". Oh, wait, that would cause a
> nasty precedent: filesystem developers might then want to have new VFS
> APIs added too, and we can't tolerate that, can we? ;-)

        Jokes aside, this "safe" permission call simply doesn't make sense
for whatever is passed to ->open() by mount(2). Again, think of the root
filesystem - _what_ permissions?

        Block device ->open() really has no way to get full-blown struct
inode. Never did. Damnit, check 1.0 and see what was passed to
->open() back then. Check how much of this "inode" is left
uninitialized. And there's nothing we can do - we _really_ have no
permissions/ownership/etc. in case of mount(). Yes, we could add another
method - ->open() for mount. The funny thing being, for more than 99% of
drivers it would be exactly the same as ->open(), modulo the different
prototype. And pardon me, but I'll say that your trick with permissions
check is a kludge - show me another case where access permissions would
act that way (after successful open() your ability to do some things
depends on permissions of inode at the time of open()).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST