thanks for the info.
i've saved a copy of this discussion in 4964815.

On Fri, Nov 28, 2008 at 01:29:27PM +0100, Joerg Schilling wrote:
> Edward Pilatowicz <[EMAIL PROTECTED]> wrote:
> > i don't know how linus differentiates between good and bad scsi
> > commands, but from a zones perspective, if a zone has access to a cdrom
> > device on a SCSI bus, then cdrecord should be able to send any SCSI
> > command that it wants to that device (including vendor specific
> > commands).  but cdrecord should be prevented from sending any SCSI
> > commands that access other devices on the same bus.  ideally, it should
> > also be prevented from abusing commands that could reset or hang the
> > entire bus, but this needs more investigation.
> This sounds reasonable. As you are able to delegate drives, you should 
> be able to delegate the permission to send any SCSI command to them as well.
> Any SCSI command _may_ hang the SCSI bus under some conditions. But similar 
> things may happen with the whole machine.
> You should know that A program that is able to send random SCSI commands to a 
> target usually is able to replace the firmware. If you like to prevent this,
> you just should not give this permission into a zone.
> BTW: There are target device resets and there are bus device resets. 
> > i'm not familiar enough with SCSI commands to know how feasible it would
> > be to implement such a filter.  if it's not technically possible, then
> > the second option is to require that a zone be given access to all the
> > devices on a scsi bus before we allow it to issue SCSI commands to that
> > bus.
> Sending a bus device reset is not a SCSI command. There is a reset line in 
> the 
> bus.
> Sending a taarget reset is done via a SCSI message that is usually not 
> directly 
> sendable from user space.
> Jörg
> -- 
>  EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
>        [EMAIL PROTECTED]                (uni)  
>        [EMAIL PROTECTED]     (work) Blog:
>  URL:
zones-discuss mailing list

Reply via email to