Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009]

[Lin Ma]

Hi Artem and all,

>> On 04/01/09 01:51, Darren J Moffat wrote:
>> > Understood and that is great information, does smserverd allow for 
>> this
>> > kind of nasty to get through it ?
>>
>> Yes, as does any solution that allows apps to use uscsi directly.
>>
>> > If possible I'd like to see it used rather than handing out 
>> sys_devices
>> > via the pfexec .bin hackery that the cdrtools case introduced and that
>> > this case is continuing with.
>>
>> You can blame cdrtools for many things, but this is not one of them. 
>> The .bin trick was done only as a convenience to the users who are 
>> used to invoke cdrecord on other OSes without sudo/pfexec. Times have 
>> changed, thanks to OpenSolaris and IPS, every OpenSolaris newbie 
>> knows about pfexec. The ultimate solution, of course, is to make 
>> pfexec implicit/always-on (what Danek alluded to earlier).
This seems a general discussion about pfexec rather than brasero specific.

Anyway I will make a few changes, move binary /usr/bin/brasero.bin to 
/usr/lib/brasero/brasero.bin, the script /usr/bin/brasero remains untouched.

>>
>> Going back to the original point: USCSI should be avoided at all 
>> costs. Only very special apps _really_ need naked USCSI, like the 
>> VirtualBox pass-thru mode for CD drives, where we cannot possibly 
>> know what SCSI commands will be issued.
>>
>> For cases like CD ripping, we should be able to provide apps with a 
>> functional API, hiding USCSI implementation in the privileged 
>> component, preferably sd driver, extending cdio(7I) if necessary; 
>> failing that, smserverd would probably be another choice. We now also 
>> have the improved cdrtools that provide programmatic access to CD 
>> ripping operations, as seen in cdda2wav-based GStreamer CDDA plugin.
> The arch of Brasero is to directly open a device and send SCSI command 
> to that device, the main framework is preparing SCSI data, invoke 
> ioctl with SCSI operator command and the data and parse the data. 
> Different platform write different backend for brasero, like FreeBSD 
> cam device and Linux SG device. So the requirement of poring it to 
> Solaris is to find a device which could accept SCSI operator command 
> and data structure. That's the reason I choose USCSI.
>
> I can't use cdio and fork any small privileged process for the brasero 
> Solaris backend, because I have to parse the information (get from 
> cdio or privileged process) and write back to the SCSI data passed 
> from brasero framework. It's very expansive and dangerous to me. And I 
> can't predict how many SCSI operators may be changed in the future.
>
> So I do think Solaris should provide a good interface for that 
> requirement instead of forcing the requirement to change.


>> Is it possible to provide a library API that applications could use,
>> or is it only possible to get this information via running a program
>> like cdda2wav as a forked process?
>
> These are not mutually exclusive: you can have a library API that 
> internally communicates with a more privileged process be it a daemon, 
> a transient process, or the kernel (which is, in many ways, is just 
> another privileged process). The key here is to minimize the amount of 
> unaudited code that runs with elevated privileges: a GUI media player 
> with megabytes of mmapped GNOME libraries is a lot of code.

Brasero is designed as OS independent application, the framework doesn't 
depend on any binaries, and heavily uses raw SCSI data. On Solaris uses 
USCSI is a better way to run it. And force it requires 'Console User' 
which gives it read permission and 'Desktop CD User' which gives it 
'sys_device' privilege. Those profiles are under Administrator's control.

Darren J Moffat's solution is really good and could provide better 
interface for CD consumer applications on Solaris. I'd like to work with 
Tamarack team to make any changes based on it or any further project 
forked from that idea.

Is there any objections and suggestions for this case?

Thanks,
lin