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 

Sending a taarget reset is done via a SCSI message that is usually not directly 
sendable from user space.


 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
       [EMAIL PROTECTED]                (uni)  
       [EMAIL PROTECTED]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
zones-discuss mailing list

Reply via email to