>
>
>On Sat, 16 Sep 2000, Alain Knaff wrote:
>
>> Ok, now could you tell me a way how to easily detect a "fake inode",
>> and I rewrite my "restore ioctl functionality patch" in a way as not
>> to break floppy root mounts.
>
>s/root//
>
>fake means NULL ->i_sb, nothing fancy about that. IS_RDONLY() used to be
>very defensive and that's the only thing that didn't let this code blow
>into your face from the very beginning. You can protect the call of
>permission() with if (inode->i_sb).
Thanks.
So I'll just make that:
/* Allow ioctls if we have write-permissions even if read-only open.
* Needed so that programs such as fdrawcmd still can work on write
* protected disks */
if ((filp->f_mode & 2) ||
(inode->i_sb && (permission(inode,2) == 0)))
filp->private_data = (void*) 8;
>However, I still think that it's
>bogus - after a look at the ioctl list it seems that most of them are
>sysctls in disguise (come on, verbosity level for debugging printk()s as
>ioctl()?)
Again, sysctl was not yet available, back when this was written.
Moreover you seem to have an interesting definition of "most": for
many of those ioctls, sysctl would be rather clumsy: FDRAWCMD,
FDSETPRM, FDCLRPRM, FDDEFPRM, FDFMTBEG, FDFMTTRK, FDFMTEND, FDFLUSH,
FDRESET, FDTWADDLE, FDEJECT. Or do you really mean that for reading a
disk, or formatting a disk, you should need sysctl?
>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?
>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? ;-)
>I can do that. It doesn't require any modifications to the core part of
>the driver (trivial character device glue + tiny parser calling the same
>functions that fd_ioctl() calls), so it should be reasonably safe.
Given your track record, I'd rather not... ;-)
>I would really like to know what uses floppy-specific ioctls, though -
>look at the callers would probably clarify the situation.
Floppy formatting programs, programs that read/write non-PC disks (ya
know, lots of people still use CP/M disks for exchanging data with
their "legacy" hardware such as synthesizers, machine tools, glass
cutting machines, etc.), floppy configuration tools, etc. Ok, so these
programs might be used less frequently than other programs, but so are
programs that use IDE specific ioctls, programs that use SCSI specific
ioctls, etc.
>
>Comments?
Alain
-
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