On Thu, Nov 27, 2008 at 09:58:58AM +0100, Joerg Schilling wrote:
> Edward Pilatowicz <[EMAIL PROTECTED]> wrote:
> > hey mark,
> > this is a long standing (4 year old) bug:
> >     4964815 Unable to burn CD's inside a non-global zone
> >
> > i just did some quick testing and i think the crux of the problem is
> > that to burn cds, both cdrw and cdrecord need to issue uscsi commands,
> > which currently requires the sys_devices privilege.  but this privilege
> > can not be added to zones for security reasons.  (the framework will
> > prevent you from adding this via zonecfg, you could hack around this by
> > editing the zone config.xml file, but i wouldn't recommend doing this.)
> >
> > what needs to happen to really support this functionality is that the
> > uscsi command space needs to be broken up into safe operations that can
> > be granted to zones via a new privilege.  currently, we don't have
> > staffing to work on this (although this issue has been discussed in our
> > long term zones storage road map).
> This kind of discussion will bring us into the same problems that are already
> present on Linux after Linus Torvalds created a list of good and bad SCSI
> commands instead of fixing the underlying bug (that allowed anyone with
> even a read-only filedescritor to send any SCSI command) :-(
> While dumb programs like cdrw may (even this is not sure) be happy with
> a limited set of permitted SCSI commands, cdrecord supports many vendor
> specific features. As you need to know both vendor and the SCSI opcode
> in order to understand what an SCSI command may do, you will either end up
> in castrated functionality of cdrecord or you need to allow all SCSI commands.

hey joerg,

thanks for chiming in, i'm not a scsi expert so your insight is

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.

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

zones-discuss mailing list

Reply via email to