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

[Darren J Moffat]

Brian Cameron wrote:
>   > We propose:
>   >
>   > - eliminate smserverd, make libsmedia open device directly;

Why elminate it ?

Given that it didn't happen in the Tamarac case it is still the 
architecture of reference for doing uscsi from an unprivileged process. 
  Unless it is completely broken (ie already very insecure) I'd rather 
see it continue to be used.

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.

>   > - create two new privileges:
>   >   - uscsi_full for full uscsi access;
>   >   - uscsi_user for limited uscsi access (no resets or aborts);
>   > - add uscsi_user to the "Basic User Profile";
> 
>   However, we ended up removing this part of the proposal - I can't
>   recall why exactly. Perhaps we moved it outside of the project scope
>   while trying to finish the project before mgmt reprioritized again :)

That looks much nicer than requiring sys_devices.  It also appears that 
maybe uscsi_user could be in the basic set and uscsi_full would 
certainly not be.

>   One thing to keep in mind is that uscsi can be used to do some nasty
>   stuff. Like make a device behave in unpredictable ways, triggering
>   dormant driver bugs; or reprogram its firmware to become a completely
>   different class (make a USB disk behave like a USB microphone); or,
>   on parallel SCSI, create bus conditions that would affect devices you
>   may not have DAC permissions for; etc.

Understood and that is great information, does smserverd allow for this 
kind of nasty to get through it ?

--
Darren J Moffat