2008/6/18 Douglas Gilbert <dgilbert@xxxxxxxxxxxx>: > Peter Jones wrote: >> >> FUJITA Tomonori wrote: >> >>> Well, this changes sg behaviour since sg's allow_ops filter has a >>> access permission different from blk_verify_command filter's. >> >> > >>> >>> I guess that the first thing you need to do is that figuring out a >>> proper access permission for each command, which sg maintainer, etc >>> can agree. It's pretty hard and that's the reason why this patch has >>> not been merged for years, I think. >> >> I don't think this logic is sound. > > That depends on your viewpoint. > > IMO all command filtering should be dropped **. Here is the last discussion to this topic. http://thread.gmane.org/gmane.linux.scsi/26229/focus=26229 Seems like people wanted to remove the filter back there but Linus was against it. So we have to options let people keep running there apps as root or with sbit or make the filter configurable. I would prefer the later.... We now have > ATA commands tunnelled through SCSI commands (e.g. via SAT) > and will soon have encrypted SCSI commands. Are per device > command filters being proposed? If not, why should we have > the same SCSI command filter for a USB BD drive and a SCSI > enclosure services (SES) device controlling a FC array, just > because they are on the same system? The patch does the filtering per device. So each device can have its own filtering logic. -- 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
