FC6 and cdburning

[Nicholas Miell]

On Fri, 2006-07-28 at 21:13 -0400, Jesse Keating wrote:
> On Friday 28 July 2006 20:58, David Nielsen wrote:
> > It is an upstream change, that much is clear it is related to the SCSI
> > command change from a while back, that does not mean we shouldn't at
> > least propose a fix or ask the reporters for more information.. We know
> > it's broken, we've known for months. This is probably the single most
> > active bug I have ever had to deal with and all we've seen is users
> > saying "me too".
> >
> > I report bugs to Fedora, my life is to short to track down every single
> > projects bugzilla, create accounts and repeat the information. I use
> > Fedora, if the maintainer of the package feels the bug report needs to
> > go upstream he can ask me to do so. The bug has not been closed as
> > NOTOURBUG and it directly affects users of Fedora. It worked with FC4,
> > we lived with the regression in FC5.. please don't make us suffer in FC6
> > as well.
> 
> DaveJ's comment still stands.  We need a way in upstream kernel to have a list 
> of safe commands per device.  This infrastructure doesn't exist right now.  
> The commands are sanitized at a different level.  We could suid cdrecord, but 
> that's a security flaw.  We could just allow all commands, but what might 
> be 'enable BURN-proof' on one drive may be 'flash firmware' on another.  I 
> seem to remember another distro had an issue that was perm damaging certain 
> cdrom drives, I wonder if this is related.  I'd much rather see a little 
> necessary work around rather than blown up drives.
> 
> So we know what needs to be done, unfortunately our kernel team doesn't have 
> the bandwidth to deal with this rightnow.  Since this is in the kernel since 
> around 2.6.8, I wonder what other distributions are doing to resolve this 
> issue....
> 

You could also try asking Joerg nicely to make cdrecord's "generic MMC
mode" actually limit itself to generic MMC commands, but I wouldn't hold
my breath waiting for any help from him.

-- 
Nicholas Miell <nmiell at comcast.net>