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

[Artem Kachitchkine]

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).

>>   > - 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.

I tried to protect you, but you keep asking questions, so here goes the 
sad tale of libsmedia:

=====
Libsmedia was introduced in Solaris 8 to avoid code duplication in 
various removable media applications (PSARC/1999/214). There was no 
smserverd daemon and it did not deal with security issues - it was 
assumed the apps were euid=0. Although libsmedia used USCSI internally 
to implement things like media formatting, it did not provide direct 
USCSI access to the apps: it was designed to shield applications from 
the complexity of raw SCSI commands.

Then it was discovered that the 'vol' driver was always using root 
credentials instead of user process' credentials (kcred vs credp), bug 
4317053, allowing non-root processes do USCSI. The bug was fixed in 
Solaris 9.

Later is was discovered that the 4317053 fix broke the libsmedia-based 
CDE format application for not-root users, bug 4344486. rmformat was not 
affected because it is setuid root. GUI apps could not be made setuid 
root, and that's when smserverd was created, to issue USCSI requests on 
behalf of non-root processes, PSARC/2000/490. It went into Solaris 9. To 
be sure: applications still didn't need to use USCSI command directly, 
libsmedia was still doing it internally.

Finally, a non-root application was discovered that actually needed to 
issue arbitrary USCSI commands: SunPCi, bug 4549011. PSARC/2001/771 
introduced smedia_uscsi_cmd() interface for that. To sum up: smserverd 
had to be created to _prevent_ regular users from doing USCSI, and yet 
we ended up _allowing_ regular users to do USCSI. I would discourage new 
apps from exploiting the hole that was punched to work around poor 
design decisions.
=====

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.

This case states: "brasero media library uses uscsi(7I) to gather 
devices/media information, e.g. speed, capacity, etc." I don't know 
about "etc", but data like media type/capacity and drive's speed 
capabilities is already collected by HAL and made available to 
non-privileged consumers.

with apologies for a long email,
-Artem