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

[Lin Ma]

Artem Kachitchkine wrote:
>
> 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.
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.

>
> 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.
I could explain "etc", here is the list:
The code in the last column is actually a SCSI command.

/**
 *    SPC1
 */

#define BRASERO_TEST_UNIT_READY_OPCODE            0x00
#define BRASERO_INQUIRY_OPCODE                0x12
#define BRASERO_MODE_SENSE_OPCODE            0x5a
#define BRASERO_MODE_SELECT_OPCODE            0x55


/**
 *    MMC1
 */

#define BRASERO_MECHANISM_STATUS_OPCODE            0xBD
#define BRASERO_READ_DISC_INFORMATION_OPCODE        0x51
#define BRASERO_READ_TRACK_INFORMATION_OPCODE        0x52
#define BRASERO_READ_TOC_PMA_ATIP_OPCODE        0x43
#define BRASERO_READ_BUFFER_CAPACITY_OPCODE        0x5C
#define BRASERO_READ_HEADER_OPCODE            0x44
#define BRASERO_READ_SUB_CHANNEL_OPCODE            0x42
#define BRASERO_READ_MASTER_CUE_OPCODE            0x59
#define BRASERO_LOAD_CD_OPCODE                0xA6
#define BRASERO_MECH_STATUS_OPCODE            0xBD
#define BRASERO_READ_CD_OPCODE                0xBE

/**
 *    MMC2
 */

#define BRASERO_GET_PERFORMANCE_OPCODE            0xac
#define BRASERO_GET_CONFIGURATION_OPCODE        0x46
#define BRASERO_READ_CAPACITY_OPCODE            0x25
#define BRASERO_READ_FORMAT_CAPACITIES_OPCODE        0x23
#define BRASERO_READ10_OPCODE                0x28

/**
 *    MMC3
 */

#define BRASERO_READ_DISC_STRUCTURE_OPCODE        0xAD


lin
>
> with apologies for a long email,
> -Artem