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

[Mark Phalan]

On Wed, 2009-04-08 at 12:11 +0100, Darren J Moffat wrote:
> 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.

3) The program will be run as root (if I correctly understand what gksu
does) which means that when browsing for files it will see a different
home directory (root's) and may not even be able to access the proper
user's home directory if on NFS. The application may also look different
due to themeing configuration , recent files list etc. From a usability
point of view this isn't very nice.

Doing the same for rhythmbox has similar issues. How would the panel
applet behave?

-M