On Sat, Jul 29, 2006 at 10:04:46AM -0700, Linus Torvalds wrote:
> We do it _correctly_ in the sane paths (ie we really have the "same table"
> in "verify_command()" in block/scsi_ioctl.c), and the thing is, when done
> correctly, the command access table is a perfectly fine idea.
Ah, that's what I was hunting for. I must have poked through every
file in drivers/scsi/ looking for that ioctl. It never occured to me
to even look in block/
I've not looked too closely at exactly which method cdrecord was using
in the numerous bug reports we've had on this, but ..
> Btw, it's entirely possible that you might hit the same problem with
> /dev/hdc too.
This may be the case.
> - only root can ever be allowed to generate commands that the kernel has
> no clue what they are doing. NO WAY can we allow a user to generate
> postentially hardware-changing special commands just because he can
> access the CD-ROM (ie how would the kernel know that it's not a command
> that says "rewrite the firmware with something that always reads goatse
> off the disk"?)
I had visions of extending verify_command() to be of the form..
if (devicevendor==PLEXTOR) {
safe_for_write(ENABLE_BURN_PROOF);
safe_for_write(ENABLE_FROBNICATOR);
}
etc..
> - if cdrecord tries to do some device-specific setup, and is upset that
> it can't do it because the user isn't root, then it's obviously a
> cdrecord bug. Which wouldn't surprise me at all
I concur it shouldn't fail completely. But at the same time, if a user
splashed out his pennies to get a modern writer with shiny features, it's
a bit crappy of us to make him be root to use them.
> - can we _please_ not
> rely on code that has been written by a certified nut-case?
It's a mystery to me why nothing better has come along over the years.
Dave
--
http://www.codemonkey.org.uk
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
