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

[Darren J Moffat]

Lin Ma wrote:
> 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?

My objection still stands since the architecture hasn't changed.

Let me offer an alternative though that it to me slightly more palatable.

The GNOME menu items for brasero invoke it using gksu.  This means that 
  if the user has "Desktop CD User" then they can run /usr/bin/brasero 
with the required additional privileges, if they don't then they will be 
prompted for the root password (assuming they can assume the root role 
if root is a role).  There would then be no wrapper script provided and 
/usr/bin/brasero would be the real binary.

Why is this better ?
	1) no hacky wrapper script
	2) Can work even when user isn't on console
	3) Doesn't break if user has "Primary Administrator", which
	   apparently can happen with cdrecord - though I haven't
	   seen or verified this personally.

The downsides are:
	1) Other Programs that invoke brasero don't get sys_devices.
	   However this could be seen as a good thing.
	2) Running brasero from the cli required explicilty using
	   a profile shell or using pfexec brasero.

I believe this should work for the related rhythmbox et al case as well.

--
Darren J Moffat