On Wed, 28 Jan 2009 17:59:11 +0000 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > The USB stack doesn't do any filtering. The SCSI stack is supposed to > > > know what commands should and should not be sent. > > > > > > Furthermore, it seems quite likely this command was sent by userspace, > > > not by the SCSI stack -- in which case the program is supposed to know > > > what commands it shouldn't send. > > > > Not sure I agree with that logic. If the USB stack KNOWS that > > non-removable devices get upset by this command, then it would be > > appropriate for it to filter those out - to protect from bugs as much > > as to protect from denial of service attacks. > > Well, I really don't think we want to get into vetting SCSI commands > over SG_IO ... that would just trip us up on the enterprise (and > probably never work anyway). Yeah, I understand now and agree with you and Alan on that one... > The problem is that hal wants to send its own SCSI commands over SG_IO. > We've spent years trying to persuade it to put the crackpipe down and > back away from the window ledge on this (because SCSI in the kernel > knows better how to handle problem devices). We have been having some > limited success recently ... we keep enhancing what sysfs provides > (safely) so that hal doesn't have to poke in with SG_IO unsafely. > > If you can find out what the actual reason hal or whatever is doing > this, we can have another go at them. Any recommendations how to best approach debugging this? Attaching strace to some processes before inserting the usb stick? /D -- Dirk Hohndel Intel Open Source Technology Center -- To unsubscribe from this list: 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
