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

[Brian Cameron]

Some further comments from the 2009/202 case:

- Darren Moffat said:

   Artem Kachitchkine wrote:
   > Darren J Moffat wrote:
   >> Why can't this case and the braseo one use the services provided
   >> by svc:/network/rpc/smserver ?  See rpc.smserverd(1M).
   >
   > Please don't use smserver/libsmedia to gain USCSI privileges.
   >
   > (Longer answer:
   > 
http://www.mail-archive.com/opensolaris-discuss@opensolaris.org/msg06641.html) 

   >
   >
   > sys_devices is needed to issue raw SCSI ioctls. I'm not sure about
   > Linux, perhaps DAC permissions are sufficient there.

   Giving out sys_devices isn't IMO the correct answer either -
   particularly given that sys_devices is such a big powerful privilege.

   Instead I'd rather see a privilege specifically for these USCSI
   ioctls.  However that still leaves the issue of why aren't the DAC
   permissions enough ?  Why do we need more protection than that
   here ?  Maybe the new uscsi privilege should be in the basic set ?

- Nicholas Williams responds to Darrent's comments above with:

   Isn't this a logindevperm sort of issue??

- Artem Kachitchkine responds:

   > Giving out sys_devices isn't IMO the correct answer either -
   > particularly given that sys_devices is such a big powerful
   > privilege.
   >
   > Instead I'd rather see a privilege specifically for these USCSI
   > ioctls.  However that still leaves the issue of why aren't the DAC
   > permissions
   > enough ?  Why do we need more protection than that here ?  Maybe
   > the new uscsi privilege should be in the basic set ?

   Quoting Tamarack (2005/399) inception materials:

   > We propose:
   >
   > - eliminate smserverd, make libsmedia open device directly;
   > - 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 :)

   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.

   -Artem