From johnf@paravon.sfbay.sun.com Fri Mar 27 11:01:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2RI1KSL008609 for ; Fri, 27 Mar 2009 11:01:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2RI0w38010798; Fri, 27 Mar 2009 18:01:18 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH60013FFE4ZN00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Mar 2009 11:01:16 -0700 (PDT) Received: from paravon.sfbay.sun.com ([192.168.83.160]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH60062DFE3MUC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Mar 2009 11:01:15 -0700 (PDT) Received: from paravon.sfbay.sun.com (localhost [127.0.0.1]) by paravon.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2RI1Fkq002058; Fri, 27 Mar 2009 11:01:15 -0700 (PDT) Received: (from johnf@localhost) by paravon.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n2RI1FiM002055; Fri, 27 Mar 2009 11:01:15 -0700 (PDT) Date: Fri, 27 Mar 2009 11:01:15 -0700 (PDT) From: John Fischer Subject: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] To: LSARC-ext@sun.com Cc: lin.ma@sun.com Message-id: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7162 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Update to Brasero 2.25.x 1.2. Name of Document Author/Supplier: Author: Lin Ma 1.3 Date of This Document: 27 March, 2009 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: Update to Brasero 2.25.x 1.2. Name of Document Author/Supplier: Lin Ma 1.3. Date of This Document: Mar/05/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: OPG / OpenSource 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@Sun.COM 1.5.2. Responsible Engineer: lin.ma@Sun.COM 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 4. Technical Description: 4.1. Details: Brasero is a application to burn CD/DVD for the Gnome Desktop. It is designed to be as simple as possible and has some unique features to enable users to create their discs easily and quickly. Instead of using gksu as described in LSARC 2008/548, this version changes the method to acquire privileges. Brasero makes use of the profile 'Console User' so that it is only available to the console user who is the default owner of scsi devices. It delivers brasero media library which uses uscsi(7I) to gather devices/media information, e.g. speed, capacity, etc. Any applications which depend on brasero media library have to handle the required privileges or follow what brasero does. According to privileges(5), brasero media library needs the following privileges to send ioctl(2) commands to scsi devices: - PRIV_SYS_DEVICES Add the following line to the file prof_attr(4) and exec_attr(4). Make console user has 'Desktop CD User' profile by default. The package will also deliver file /usr/bin/brasero which is a script to run 'pfexec /usr/bin/brasero.bin' to acquire above privileges. prof_attr: Desktop CD User:::Access CD for desktop user: Console User::::profiles=Desktop CD User exec_attr: Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices 4.2. Bug/RFE Number(s): 6770524 4.5. Interfaces Changes: |---+-------------------------+-------------+-----------------------| | | Imported | Stability | Comments | |---+-------------------------+-------------+-----------------------| | - | GKsu | Uncommitted | LSARC 2006/348 GTK+ | | | | | Authorisation Library | |---+-------------------------+-------------+-----------------------| | + | /usr/bin/pfexec | Committed | PSARC 2002/188 | |---+-------------------------+-------------+-----------------------| | + | /etc/security/exec_attr | Committed | | |---+-------------------------+-------------+-----------------------| |---+----------------------------------------+---------------+---------------| | | Exported | Stability | Comments | |---+----------------------------------------+---------------+---------------| | ! | /usr/bin/brasero.bin | Volatile | Binary | |---+----------------------------------------+---------------+---------------| | + | /usr/bin/brasero | Volatile | Script | |---+----------------------------------------+---------------+---------------| | ! | All brasero backends | Private | Brasero | | | /usr/lib/brasero/plugins/*.so | | backends | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/libbrasero-media.so | Consolidation | Brasero media | | | | Private | library [1] | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/pkgconfig/libbrasero-media.pc | Consolidation | | | | | Private | | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/nautilus/extensions-2.0/ | Consolidation | Nautilus | | | libnautilus-brasero-extension.so | Private | extension | |---+----------------------------------------+---------------+---------------| | ! | SUNWgnome-cd-burner | Uncommitted | Package | | ! | SUNWgnome-cd-burner-root | Uncommitted | name | | + | SUNWgnome-cd-burner-devel | Uncommitted | changes | |---+----------------------------------------+---------------+---------------| | - | SUNWbrasero | Obsolete | Old package | | - | SUNWbrasero-root | Uncommitted | names these | | | | | will be | | | | | removed | |---+----------------------------------------+---------------+---------------| [1] The library for accessing scsi devices requires 'sys_devices'. It could be linked to other desktop applications. [2] The first column within the interface tables refers to the following: '+' means that the interface was added '-' means that the interface was removed '!' means that the interface was changed 4.7. Admin/Config Impact: Since brasero is for console users by default, it doesn't take care of the ownership of a scsi device. If the admin wants to give non-console users the ability to use brasero, he has to append privilege 'file_dac_read' to line 'Desktop CD User/brasero' in exec_attr, like: Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices,file_dac_read 4.11. Security Impact: A not Privilege Awareness(NPA) command excuted by the user (who has 'Primary Administrator' profile) with pfexec(1) will be matched the line: Primary Administrator:suser:cmd:::*:uid=0;gid=0 which will become a root process. The result is the reason of CR#6749728 eject function doesn't work. A temporary solution is to add the following line to exec_attr(4): Primary Administrator:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices 5. Reference Documents: LSARC 2008/548 Brasero 0.8.x RFE - 6770524 More information about Brasero can be found at these locations: http://www.gnome.org/projects/brasero http://www.gnomefiles.org/app.php/Brasero 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS - Desktop 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Mark.Carlson@sun.com Mon Mar 30 18:16:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2V1GmKX003762 for ; Mon, 30 Mar 2009 18:16:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2V1Gjpe014976 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 31 Mar 2009 02:16:47 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHC00D07JJY9600@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 30 Mar 2009 18:16:46 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHC0014FJJXNS60@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 30 Mar 2009 18:16:46 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2V1GjIA004118 for ; Tue, 31 Mar 2009 01:16:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHC00600JALAE00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 30 Mar 2009 19:16:45 -0600 (MDT) Received: from Macintosh-335.local ([unknown] [129.150.33.232]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHC00LTNJJVYR30@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 30 Mar 2009 19:16:43 -0600 (MDT) Date: Mon, 30 Mar 2009 19:16:38 -0600 From: "Mark A. Carlson" Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> Sender: Mark.Carlson@sun.com To: LSARC-ext@sun.com Cc: Lin.Ma@sun.com Message-id: <49D16EF6.4090001@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_c40447x+DcXTb0TXXIEX3Q)" X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 17061 This is a multi-part message in MIME format. --Boundary_(ID_c40447x+DcXTb0TXXIEX3Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT +1 -- mark John Fischer wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Update to Brasero 2.25.x > 1.2. Name of Document Author/Supplier: > Author: Lin Ma > 1.3 Date of This Document: > 27 March, 2009 > 4. Technical Description > 1. Introduction > 1.1. Project/Component Working Name: > > Update to Brasero 2.25.x > > 1.2. Name of Document Author/Supplier: > > Lin Ma > > 1.3. Date of This Document: > > Mar/05/09 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: > > Solaris PAC > > 1.4.2. The ARC(s) you expect to review your project: > > LSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > robert.odea@sun.com > > 1.4.4. The name of your business unit: > > OPG / OpenSource > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@Sun.COM > 1.5.2. Responsible Engineer: lin.ma@Sun.COM > 1.5.3. Marketing Manager: glynn.foster@sun.com > 1.5.4. Interest List: desktop-discuss@opensolaris.org > > 4. Technical Description: > > 4.1. Details: > > Brasero is a application to burn CD/DVD for the Gnome Desktop. > It is designed to be as simple as possible and has some unique > features to enable users to create their discs easily and quickly. > > Instead of using gksu as described in LSARC 2008/548, this version > changes the method to acquire privileges. > > Brasero makes use of the profile 'Console User' so that it is only > available to the console user who is the default owner of scsi > devices. It delivers brasero media library which uses uscsi(7I) to > gather devices/media information, e.g. speed, capacity, etc. Any > applications which depend on brasero media library have to handle > the required privileges or follow what brasero does. > > According to privileges(5), brasero media library needs the > following privileges to send ioctl(2) commands to scsi devices: > > - PRIV_SYS_DEVICES > > Add the following line to the file prof_attr(4) and > exec_attr(4). Make console user has 'Desktop CD User' profile by > default. The package will also deliver file /usr/bin/brasero which > is a script to run 'pfexec /usr/bin/brasero.bin' to acquire above > privileges. > > prof_attr: > Desktop CD User:::Access CD for desktop user: > Console User::::profiles=Desktop CD User > > exec_attr: > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices > > 4.2. Bug/RFE Number(s): > > 6770524 > > 4.5. Interfaces Changes: > > |---+-------------------------+-------------+-----------------------| > | | Imported | Stability | Comments | > |---+-------------------------+-------------+-----------------------| > | - | GKsu | Uncommitted | LSARC 2006/348 GTK+ | > | | | | Authorisation Library | > |---+-------------------------+-------------+-----------------------| > | + | /usr/bin/pfexec | Committed | PSARC 2002/188 | > |---+-------------------------+-------------+-----------------------| > | + | /etc/security/exec_attr | Committed | | > |---+-------------------------+-------------+-----------------------| > > |---+----------------------------------------+---------------+---------------| > | | Exported | Stability | Comments | > |---+----------------------------------------+---------------+---------------| > | ! | /usr/bin/brasero.bin | Volatile | Binary | > |---+----------------------------------------+---------------+---------------| > | + | /usr/bin/brasero | Volatile | Script | > |---+----------------------------------------+---------------+---------------| > | ! | All brasero backends | Private | Brasero | > | | /usr/lib/brasero/plugins/*.so | | backends | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/libbrasero-media.so | Consolidation | Brasero media | > | | | Private | library [1] | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/pkgconfig/libbrasero-media.pc | Consolidation | | > | | | Private | | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/nautilus/extensions-2.0/ | Consolidation | Nautilus | > | | libnautilus-brasero-extension.so | Private | extension | > |---+----------------------------------------+---------------+---------------| > | ! | SUNWgnome-cd-burner | Uncommitted | Package | > | ! | SUNWgnome-cd-burner-root | Uncommitted | name | > | + | SUNWgnome-cd-burner-devel | Uncommitted | changes | > |---+----------------------------------------+---------------+---------------| > | - | SUNWbrasero | Obsolete | Old package | > | - | SUNWbrasero-root | Uncommitted | names these | > | | | | will be | > | | | | removed | > |---+----------------------------------------+---------------+---------------| > > [1] The library for accessing scsi devices requires 'sys_devices'. It > could be linked to other desktop applications. > > [2] The first column within the interface tables refers to the following: > '+' means that the interface was added > '-' means that the interface was removed > '!' means that the interface was changed > > 4.7. Admin/Config Impact: > > Since brasero is for console users by default, it doesn't take > care of the ownership of a scsi device. If the admin wants to give > non-console users the ability to use brasero, he has to append > privilege 'file_dac_read' to line 'Desktop CD User/brasero' in > exec_attr, like: > > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices,file_dac_read > > 4.11. Security Impact: > > A not Privilege Awareness(NPA) command excuted by the user (who has > 'Primary Administrator' profile) with pfexec(1) will be matched > the line: > > Primary Administrator:suser:cmd:::*:uid=0;gid=0 > > which will become a root process. The result is the reason of > CR#6749728 eject function doesn't work. > > A temporary solution is to add the following line to exec_attr(4): > > Primary Administrator:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices > > 5. Reference Documents: > > LSARC 2008/548 Brasero 0.8.x > > RFE - 6770524 > > More information about Brasero can be found at these locations: > > http://www.gnome.org/projects/brasero > http://www.gnomefiles.org/app.php/Brasero > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > JDS - Desktop > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > -- * Mark A. Carlson * Sr. Architect *Systems Group* Phone x69559 / 303-223-6139 Email Mark.Carlson@Sun.COM --Boundary_(ID_c40447x+DcXTb0TXXIEX3Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT +1

-- mark

John Fischer wrote: 
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 Update to Brasero 2.25.x
    1.2. Name of Document Author/Supplier:
	 Author:  Lin Ma
    1.3  Date of This Document:
	27 March, 2009
4. Technical Description
1. Introduction
   1.1. Project/Component Working Name:

	Update to Brasero 2.25.x

   1.2. Name of Document Author/Supplier:

	Lin Ma

   1.3. Date of This Document:

	Mar/05/09

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:

		Solaris PAC

	1.4.2. The ARC(s) you expect to review your project:

		LSARC

	1.4.3. The Director/VP who is "Sponsoring" this project:

		robert.odea@sun.com

	1.4.4. The name of your business unit:

		OPG / OpenSource

   1.5. Email Aliases:
	1.5.1. Responsible Manager:     leo.binchy@Sun.COM
	1.5.2. Responsible Engineer:    lin.ma@Sun.COM
	1.5.3. Marketing Manager:       glynn.foster@sun.com
	1.5.4. Interest List:           desktop-discuss@opensolaris.org

4. Technical Description:

    4.1. Details: 

    Brasero is a application to burn CD/DVD for the Gnome Desktop.
    It is designed to be as simple as possible and has some unique
    features to enable users to create their discs easily and quickly.

    Instead of using gksu as described in LSARC 2008/548, this version 
    changes the method to acquire privileges.

    Brasero makes use of the profile 'Console User' so that it is only
    available to the console user who is the default owner of scsi
    devices. It delivers brasero media library which uses uscsi(7I) to
    gather devices/media information, e.g. speed, capacity, etc. Any
    applications which depend on brasero media library have to handle
    the required privileges or follow what brasero does.

    According to privileges(5), brasero media library needs the
    following privileges to send ioctl(2) commands to scsi devices:

    - PRIV_SYS_DEVICES
    
    Add the following line to the file prof_attr(4) and
    exec_attr(4). Make console user has 'Desktop CD User' profile by
    default. The package will also deliver file /usr/bin/brasero which
    is a script to run 'pfexec /usr/bin/brasero.bin' to acquire above
    privileges.

    prof_attr:
    Desktop CD User:::Access CD for desktop user:
    Console User::::profiles=Desktop CD User

    exec_attr:
    Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices

    4.2. Bug/RFE Number(s):

	6770524
    
    4.5. Interfaces Changes:

|---+-------------------------+-------------+-----------------------|
|   | Imported                | Stability   | Comments              |
|---+-------------------------+-------------+-----------------------|
| - | GKsu                    | Uncommitted | LSARC 2006/348 GTK+   |
|   |                         |             | Authorisation Library |
|---+-------------------------+-------------+-----------------------|
| + | /usr/bin/pfexec         | Committed   | PSARC 2002/188        |
|---+-------------------------+-------------+-----------------------|
| + | /etc/security/exec_attr | Committed   |                       |
|---+-------------------------+-------------+-----------------------|

|---+----------------------------------------+---------------+---------------|
|   | Exported                               | Stability     | Comments      |
|---+----------------------------------------+---------------+---------------|
| ! | /usr/bin/brasero.bin                   | Volatile      | Binary        |
|---+----------------------------------------+---------------+---------------|
| + | /usr/bin/brasero                       | Volatile      | Script        |
|---+----------------------------------------+---------------+---------------|
| ! | All brasero backends                   | Private       | Brasero       |
|   | /usr/lib/brasero/plugins/*.so          |               | backends      |
|---+----------------------------------------+---------------+---------------|
| + | /usr/lib/libbrasero-media.so           | Consolidation | Brasero media |
|   |                                        | Private       | library [1]   |
|---+----------------------------------------+---------------+---------------|
| + | /usr/lib/pkgconfig/libbrasero-media.pc | Consolidation |               |
|   |                                        | Private       |               |
|---+----------------------------------------+---------------+---------------|
| + | /usr/lib/nautilus/extensions-2.0/      | Consolidation | Nautilus      |
|   | libnautilus-brasero-extension.so       | Private       | extension     |
|---+----------------------------------------+---------------+---------------|
| ! | SUNWgnome-cd-burner                    | Uncommitted   | Package       |
| ! | SUNWgnome-cd-burner-root               | Uncommitted   | name          |
| + | SUNWgnome-cd-burner-devel              | Uncommitted   | changes       |
|---+----------------------------------------+---------------+---------------|
| - | SUNWbrasero                            | Obsolete      | Old package   |
| - | SUNWbrasero-root                       | Uncommitted   | names these   |
|   |                                        |               | will be       |
|   |                                        |               | removed       |
|---+----------------------------------------+---------------+---------------|

[1] The library for accessing scsi devices requires 'sys_devices'. It
could be linked to other desktop applications.

[2] The first column within the interface tables refers to the following:
    '+' means that the interface was added
    '-' means that the interface was removed
    '!' means that the interface was changed

    4.7. Admin/Config Impact:

    Since brasero is for console users by default, it doesn't take
    care of the ownership of a scsi device. If the admin wants to give
    non-console users the ability to use brasero, he has to append
    privilege 'file_dac_read' to line 'Desktop CD User/brasero' in
    exec_attr, like:

    Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices,file_dac_read

    4.11. Security Impact:

    A not Privilege Awareness(NPA) command excuted by the user (who has
    'Primary Administrator' profile) with pfexec(1) will be matched
    the line:

    Primary Administrator:suser:cmd:::*:uid=0;gid=0

    which will become a root process. The result is the reason of
    CR#6749728 eject function doesn't work.
    
    A temporary solution is to add the following line to exec_attr(4):

    Primary Administrator:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices

5. Reference Documents:

   LSARC 2008/548  Brasero 0.8.x

   RFE - 6770524

   More information about Brasero can be found at these locations:

   http://www.gnome.org/projects/brasero
   http://www.gnomefiles.org/app.php/Brasero

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		JDS - Desktop
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

--
Mark A. Carlson
Sr. Architect

Systems Group
Phone x69559 / 303-223-6139
Email Mark.Carlson@Sun.COM

--Boundary_(ID_c40447x+DcXTb0TXXIEX3Q)-- From Brian.Cameron@sun.com Tue Mar 31 10:14:32 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2VHEWkR025916 for ; Tue, 31 Mar 2009 10:14:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2VHESdV018141 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 31 Mar 2009 10:14:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHD00711RW6N700@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 31 Mar 2009 10:14:30 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHD00MRBRW535D0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 31 Mar 2009 10:14:30 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VHETdw011295 for ; Tue, 31 Mar 2009 17:14:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHD00H00RAAH200@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 31 Mar 2009 11:14:29 -0600 (MDT) Received: from [129.153.250.178] ([unknown] [129.153.250.178]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHD00I8ZRVY3Y00@mail-amer.sun.com>; Tue, 31 Mar 2009 11:14:23 -0600 (MDT) Date: Tue, 31 Mar 2009 12:13:46 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> Sender: Brian.Cameron@sun.com To: John Fischer Cc: LSARC-ext@sun.com, Lin.Ma@sun.com Message-id: <49D24F4A.30105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090323 Thunderbird/3.0b2 Status: RO Content-Length: 1986 I submitted the separate case LSARC 2009/202 to highlight that similar changes are needed for totem, rhythmbox, and sound-juicer. The following questions were raised, and I think it makes more sense to resolve these issues in this LSARC 2009/201 case. If the Brasero case changes in any way, I think it makes sense for totem, rhythmbox, and sound-juicer to do things the same way. Issues raised were: - Danek Duvall suggested that we do not deliver a script called /usr/bin/brasero and not move the binary to /usr/bin/brasero.bin. Instead of doing this, he suggests that we instead maintain a patch so that programs re-exec themselves underpfexec if they don't have sys_devices, rather than cluttering up /usr/bin with scripts. This seems reasonable to me. Lin? - Darren Moffat asked; > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices How does this work on Linux kernel based systems ? How do these programs get access to the devices ? Given what these programs do I suspect what what is really wanted is read and sometimes write access to the CD/DVD device nodes. Running them with sys_devices to over come that feels really wrong. Particularly given that "Desktop CD User" is ultimately being added to "Console User". Can't we instead use logindevperm so that the CD/DVD devices are made available with suitable unix permissions - just like we already do for USB removable-media devices, generic usb devices, video devices etc. While there exists precedent for this hack I really don't like it and having it proliferated further isn't a good idea. - Darren Moffat also asked: Why can't this case and the braseo one use the services provided by svc:/network/rpc/smserver ? See rpc.smserverd(1M). PSARC/2000/490 is the reference for the smserver architecture. Lin, I know that you did more research on the security-related changes to brasero. Could you respond? Thanks, Brian From danek.duvall@sun.com Tue Mar 31 10:20:59 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2VHKwR6026310 for ; Tue, 31 Mar 2009 10:20:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2VHKm50009252 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 1 Apr 2009 01:20:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHD00701S6VZZ00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 31 Mar 2009 10:20:55 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHD00M70S6V3JD0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 31 Mar 2009 10:20:55 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (mumak.SFBay.Sun.COM [129.146.229.4]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2VHKr4Y035554; Tue, 31 Mar 2009 10:20:53 -0700 (PDT) Received: from mumak.SFBay.Sun.COM (loghost [127.0.0.1]) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2VHNAlY005798; Tue, 31 Mar 2009 10:23:10 -0700 (PDT) Received: (from dduvall@localhost) by mumak.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2VHNAAY005797; Tue, 31 Mar 2009 10:23:10 -0700 (PDT) Date: Tue, 31 Mar 2009 10:23:10 -0700 From: Danek Duvall Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D24F4A.30105@sun.com> To: Brian Cameron Cc: John Fischer , LSARC-ext@sun.com, Lin.Ma@sun.com Message-id: <20090331172310.GM7978@mumak.SFBay.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49D24F4A.30105@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 542 On Tue, Mar 31, 2009 at 12:13:46PM -0500, Brian Cameron wrote: > - Danek Duvall suggested that we do not deliver a script called > /usr/bin/brasero and not move the binary to /usr/bin/brasero.bin. > Instead of doing this, he suggests that we instead maintain a patch so > that programs re-exec themselves underpfexec if they don't have > sys_devices, rather than cluttering up /usr/bin with scripts. > > This seems reasonable to me. Lin? FWIW, Darren's suggestion seems to be a better suggestion, I think, if it's workable. Danek From Brian.Cameron@sun.com Tue Mar 31 10:40:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2VHennM027607 for ; Tue, 31 Mar 2009 10:40:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2VHemrB057704 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 31 Mar 2009 11:40:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHD00M0JT3ZWG00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 10:40:48 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHD00KVTT3ZUG10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 10:40:47 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VHekZe000813 for ; Tue, 31 Mar 2009 17:40:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHD00H00RAAH200@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 11:40:46 -0600 (MDT) Received: from [129.153.250.178] ([unknown] [129.153.250.178]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHD00IODT3M3Y60@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 11:40:35 -0600 (MDT) Date: Tue, 31 Mar 2009 12:39:59 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] Sender: Brian.Cameron@sun.com To: LSARC-ext@sun.com Cc: Lin Ma , John.Fischer@sun.com Message-id: <49D2556F.6050905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090323 Thunderbird/3.0b2 Status: RO Content-Length: 543 Artem Kachitchkine also made this comment in the LSARC 2009/202 case. -------- Original Message -------- 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. -Artem From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.de Tue Mar 31 13:33:47 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2VKXjFm002438 for ; Tue, 31 Mar 2009 13:33:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2VKXgGS002505 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 31 Mar 2009 13:33:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE00K271490D00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 31 Mar 2009 14:33:45 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE00F5L14878F0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 31 Mar 2009 14:33:44 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2VKUN3R024367 for ; Tue, 31 Mar 2009 20:33:44 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-3550018 for LSARC-ext@sun.com; Tue, 31 Mar 2009 20:33:39 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-43126 for LSARC-ext@sun.com; Tue, 31 Mar 2009 20:33:39 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay1i.sun.com with ESMTP id BT-MMP-47720600 for LSARC-ext@sun.com; Tue, 31 Mar 2009 20:33:38 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 8233063C091; Tue, 31 Mar 2009 22:33:37 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id BEE3F63C08D; Tue, 31 Mar 2009 22:33:36 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id n2VKXamW010754; Tue, 31 Mar 2009 22:33:37 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 22:33:36 +0200 Date: Tue, 31 Mar 2009 22:33:36 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D24F4A.30105@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.de To: johnf@paravon.sfbay.sun.com, Lin.Ma@sun.com, LSARC-ext@sun.com, Brian.Cameron@sun.com Message-id: <49d27e20.OvnchbOMMdVurkP6%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.324sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49D24F4A.30105@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 31 Mar 2009 20:33:36.0855 (UTC) FILETIME=[F7E6C670:01C9B23F] Status: RO Content-Length: 2790 Brian Cameron wrote: > I submitted the separate case LSARC 2009/202 to highlight that > similar changes are needed for totem, rhythmbox, and sound-juicer. > > The following questions were raised, and I think it makes more > sense to resolve these issues in this LSARC 2009/201 case. > If the Brasero case changes in any way, I think it makes sense > for totem, rhythmbox, and sound-juicer to do things the same > way. The preferred way is to call cdrecord with the right options and to read the results to get the information that needs more privileges. Cdrecord is planned to deliver all the needed information. > Issues raised were: > > - Danek Duvall suggested that we do not deliver a script > called /usr/bin/brasero and not move the binary > to /usr/bin/brasero.bin. Instead of doing this, he suggests > that we instead maintain a patch so that programs re-exec > themselves underpfexec if they don't have sys_devices, > rather than cluttering up /usr/bin with scripts. > > This seems reasonable to me. Lin? > > - Darren Moffat asked; > > > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices > > How does this work on Linux kernel based systems ? How do these > programs get access to the devices ? Linux is inherently insecure. There was a bug in the Linux driver system in 2004 that allowed all SCSI commands to be send by any user to any device in case it could open a device read only. At that time, some software started being based on tha bug and Linus Torvalds did not fix the bug (which would have the result to disable these programs) but rather changed the kernel interfaces in a way that corretly working programs like cdrecord did not work anymore. > Given what these programs do I suspect what what is really wanted is > read and sometimes write access to the CD/DVD device nodes. > > Running them with sys_devices to over come that feels really wrong. > Particularly given that "Desktop CD User" is ultimately being added > to "Console User". > > Can't we instead use logindevperm so that the CD/DVD devices are made > available with suitable unix permissions - just like we already do > for USB removable-media devices, generic usb devices, video devices > etc. > > While there exists precedent for this hack I really don't like it > and having it proliferated further isn't a good idea. How about changing brasero to call cdrecord to get the information? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Brian.Cameron@sun.com Tue Mar 31 15:52:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2VMqXuC021538 for ; Tue, 31 Mar 2009 15:52:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2VMqHu0011160 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 31 Mar 2009 23:52:32 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE00F017JKCK00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 15:52:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE00FQH7JJWLB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 15:52:32 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2VMqVSg000829 for ; Tue, 31 Mar 2009 22:52:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHE0060071GAP00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 16:52:31 -0600 (MDT) Received: from [129.153.250.132] ([unknown] [129.153.250.132]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHE007T97J74XB0@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 16:52:19 -0600 (MDT) Date: Tue, 31 Mar 2009 17:51:44 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D2556F.6050905@sun.com> Sender: Brian.Cameron@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, Lin Ma , John.Fischer@sun.com Message-id: <49D29E80.9030301@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090323 Thunderbird/3.0b2 Status: RO Content-Length: 2542 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 From Lin.Ma@Sun.COM Tue Mar 31 19:14:08 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n312E724027871 for ; Tue, 31 Mar 2009 19:14:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n312DxQ5002189 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 1 Apr 2009 10:14:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE00G0XGVH6O00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 19:14:05 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE00243GVG9WB0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 31 Mar 2009 19:14:04 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n312E3n3012719 for ; Wed, 01 Apr 2009 02:14:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHE00000GUDA700@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 03:14:03 +0100 (BST) Received: from [129.158.217.224] ([unknown] [129.158.217.224]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHE008O8GVCUJE0@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 03:14:03 +0100 (BST) Date: Wed, 01 Apr 2009 10:13:54 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D29E80.9030301@sun.com> Sender: Lin.Ma@Sun.COM To: Brian Cameron , Darren J Moffat , Artem Kachitchkine Cc: LSARC-ext@Sun.COM, John.Fischer@Sun.COM Message-id: <49D2CDE2.1000008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1848 > - 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"; Above solution is good to me. I'd like accept it and update brasero to rely on either the new privilege or any library like libsmedia. But before the proposal is implemented, I think cases 201 and 202 are good as a temporary solution because they limit the account who could use uscsi. Are there any objections? BTW, who can give me a pointer to the doc of libsmedia? lin > > 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 From Darren.Moffat@Sun.COM Wed Apr 1 01:51:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n318pYbo025465 for ; Wed, 1 Apr 2009 01:51:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n318pWi1015276 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 1 Apr 2009 01:51:34 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHE00409Z9X1K00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 02:51:33 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHE0049HZ9V8GD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 02:51:32 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n318pVZD011918 for ; Wed, 01 Apr 2009 08:51:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHE00I00Z704A00@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 09:51:31 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHE00M63Z9IPA70@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 01 Apr 2009 09:51:19 +0100 (BST) Date: Wed, 01 Apr 2009 09:51:17 +0100 From: Darren J Moffat Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D29E80.9030301@sun.com> Sender: Darren.Moffat@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, Lin Ma Message-id: <49D32B05.3020103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1659 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 From Artem.Kachitchkin@sun.com Wed Apr 1 11:57:00 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31Iv0GI029636 for ; Wed, 1 Apr 2009 11:57:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31Iuwnf018932 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 1 Apr 2009 11:57:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00E2DRAZXN00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 12:56:59 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF008UCRAW0480@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 12:56:57 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31IuuPk007372 for ; Wed, 01 Apr 2009 11:56:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHF00M00R31K900@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 11:56:56 -0700 (PDT) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHF003NIRA8EZ70@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 11:56:33 -0700 (PDT) Date: Wed, 01 Apr 2009 11:56:27 -0700 From: Artem Kachitchkine Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D32B05.3020103@Sun.COM> Sender: Artem.Kachitchkin@sun.com To: Darren J Moffat Cc: Brian Cameron , LSARC-ext@sun.com Message-id: <49D3B8DB.9010205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 3837 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 From Brian.Cameron@sun.com Wed Apr 1 12:51:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31JpN3D027847 for ; Wed, 1 Apr 2009 12:51:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n31JpDDG021327 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 2 Apr 2009 03:51:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00A03TTLWK00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 12:51:21 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF008QTTTKAUB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 12:51:20 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n31JpKLM019742 for ; Wed, 01 Apr 2009 19:51:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHF00B00T2FCO00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:51:20 -0600 (MDT) Received: from [10.0.0.8] ([unknown] [99.141.96.126]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHF00DJPTTEIL80@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:51:14 -0600 (MDT) Date: Wed, 01 Apr 2009 14:50:40 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D3B8DB.9010205@sun.com> Sender: Brian.Cameron@sun.com To: Artem Kachitchkine Cc: Darren J Moffat , LSARC-ext@sun.com Message-id: <49D3C590.4030003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090323 Thunderbird/3.0b2 Status: RO Content-Length: 603 Artem: > 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. 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? Brian From Artem.Kachitchkin@Sun.COM Wed Apr 1 13:15:18 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n31KFIOR002038 for ; Wed, 1 Apr 2009 13:15:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n31KFIhW024294 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 1 Apr 2009 13:15:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHF00D05UXHY400@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:15:17 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHF00BRXUXGQP10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:15:16 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n31KFGa3020046 for ; Wed, 01 Apr 2009 13:15:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHF00200TVTOQ00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:15:16 -0700 (PDT) Received: from [129.146.104.83] ([unknown] [129.146.104.83]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHF007F2UXAU0F0@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 13:15:10 -0700 (PDT) Date: Wed, 01 Apr 2009 13:15:04 -0700 From: Artem Kachitchkine Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D3C590.4030003@sun.com> Sender: Artem.Kachitchkin@Sun.COM To: Brian Cameron Cc: Darren J Moffat , LSARC-ext@Sun.COM Message-id: <49D3CB48.9050502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D3C590.4030003@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081215) Status: RO Content-Length: 1022 >> 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. > > 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. -Artem From Lin.Ma@sun.com Wed Apr 1 19:32:14 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n322WCJ8003595 for ; Wed, 1 Apr 2009 19:32:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n322W75J000513 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 2 Apr 2009 03:32:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHG00G0PCDLGF00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 19:32:09 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHG007NXCDKME40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 01 Apr 2009 19:32:09 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n322W7ej009031 for ; Thu, 02 Apr 2009 02:32:07 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHG00600CCJ1W00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 02 Apr 2009 03:32:07 +0100 (BST) Received: from [129.158.217.127] ([unknown] [129.158.217.127]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHG0092SCDGZI70@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 02 Apr 2009 03:32:07 +0100 (BST) Date: Thu, 02 Apr 2009 10:31:57 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D3B8DB.9010205@sun.com> Sender: Lin.Ma@sun.com To: Artem Kachitchkine Cc: Darren J Moffat , Brian Cameron , LSARC-ext@sun.com Message-id: <49D4239D.9060003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 6252 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 From Lin.Ma@Sun.COM Tue Apr 7 20:29:08 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n383T74Y023669 for ; Tue, 7 Apr 2009 20:29:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n383T6tc004642 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 04:29:06 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHR00307J0IYE00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 07 Apr 2009 20:29:06 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHR00GV4J0GHT40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 07 Apr 2009 20:29:05 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n383T4LV005999 for ; Wed, 08 Apr 2009 03:29:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHR00A00IQ0T800@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:29:04 +0100 (BST) Received: from [129.158.217.127] ([unknown] [129.158.217.127]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHR005X1IZZHCB0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:28:50 +0100 (BST) Date: Wed, 08 Apr 2009 11:28:42 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49D4239D.9060003@Sun.COM> Sender: Lin.Ma@Sun.COM To: Artem Kachitchkine Cc: LSARC-ext@Sun.COM Message-id: <49DC19EA.4030002@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 4026 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? Thanks, lin From Darren.Moffat@sun.com Wed Apr 8 04:11:41 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38BBfRN024033 for ; Wed, 8 Apr 2009 04:11:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38BBccR000183 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 05:11:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00I074FG9A00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:11:40 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS001F74FF7LD0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:11:40 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38BBcKo012515 for ; Wed, 08 Apr 2009 11:11:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS004003PO7U00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:11:38 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS00I5Y4EMP170@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:11:11 +0100 (BST) Date: Wed, 08 Apr 2009 12:11:09 +0100 From: Darren J Moffat Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DC19EA.4030002@Sun.COM> Sender: Darren.Moffat@sun.com To: Lin Ma Cc: Artem Kachitchkine , LSARC-ext@sun.com Message-id: <49DC864D.8000506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 5260 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. I believe this should work for the related rhythmbox et al case as well. -- Darren J Moffat From Mark.Phalan@sun.com Wed Apr 8 04:39:30 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38BdUtI018890 for ; Wed, 8 Apr 2009 04:39:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38BdTta016568 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 05:39:29 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00B015PRCW00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:39:27 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00N5J5PQ39B0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 04:39:27 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38BdQEN016461 for ; Wed, 08 Apr 2009 11:39:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS005003RR8R00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:39:26 +0100 (BST) Received: from [129.157.71.112] ([unknown] [129.157.71.112]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS00EYE5POXDA0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:39:25 +0100 (BST) Date: Wed, 08 Apr 2009 13:39:15 +0200 From: Mark Phalan Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DC864D.8000506@Sun.COM> Sender: Mark.Phalan@sun.com To: Darren J Moffat Cc: Lin Ma , Artem Kachitchkine , LSARC-ext@sun.com Message-id: <1239190755.4418.40.camel@zup> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> <49DC864D.8000506@Sun.COM> Status: RO Content-Length: 5917 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 From Darren.Moffat@sun.com Wed Apr 8 04:55:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38BtfKF020070 for ; Wed, 8 Apr 2009 04:55:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38BtRmx002848 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 12:55:40 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00G136GRIM00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 05:55:39 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00LU46GQBOD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 05:55:39 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38BtcUj000409 for ; Wed, 08 Apr 2009 11:55:38 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS008005FXXW00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:55:38 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS00B9Y6GCSD60@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 12:55:25 +0100 (BST) Date: Wed, 08 Apr 2009 12:55:24 +0100 From: Darren J Moffat Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <1239190755.4418.40.camel@zup> Sender: Darren.Moffat@sun.com To: Mark Phalan Cc: Lin Ma , Artem Kachitchkine , LSARC-ext@sun.com Message-id: <49DC90AC.3030408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> <49DC864D.8000506@Sun.COM> <1239190755.4418.40.camel@zup> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1900 Mark Phalan wrote: > 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. gksu on OpenSolaris has been modified (though strangely the man page doesn't talk about this - I'll file a man page bug) to first look to see if the user has an RBAC profile for the command being run if it does then it uses pfexec(1). If the user doesn't have a direct RBAC profile entry for the command but the user can assume a role that does have an RBAC profile entry then gksu prompts for the role password. Failing all that then gksu prompts for the root password (which given gksu is really using su(1M) will fail it root is a role that the user can't assume). For example, I created the "Desktop CD User" profile and assign it as the case defines it to "CONSOLE_USER" in policy.conf and have an entry for rhythmbox with privs=sys_devices in exec_attr. I then used gksu to start up rhythmbox and we see: islay:pts/16$ gksu /usr/bin/rhythmbox islay:pts/16$ ppriv $(pgrep rhythmbox) 27049: /usr/lib/rhythmbox-metadata unix:tmpdir=/tmp flags = E: basic,sys_devices I: basic,sys_devices P: basic,sys_devices L: all 27037: /usr/bin/rhythmbox flags = E: basic,sys_devices I: basic,sys_devices P: basic,sys_devices L: all islay:pts/16$ pcred $(pgrep rhythmbox) 27049: e/r/suid=101 e/r/sgid=10 27037: e/r/suid=101 e/r/sgid=10 > Doing the same for rhythmbox has similar issues. How would the panel > applet behave? The panel applet is just a window of the rhythmbox application it isn't a separate application. -- Darren J Moffat From Mark.Phalan@Sun.COM Wed Apr 8 05:09:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38C9mHq021072 for ; Wed, 8 Apr 2009 05:09:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38C9lvp036700 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 06:09:47 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00H01749SP00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 06:09:46 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00L9K748BMF0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 06:09:45 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38C9i0f020960 for ; Wed, 08 Apr 2009 12:09:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS00G00704CV00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 13:09:44 +0100 (BST) Received: from [129.157.71.112] ([unknown] [129.157.71.112]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS00CGL743M980@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 13:09:40 +0100 (BST) Date: Wed, 08 Apr 2009 14:09:31 +0200 From: Mark Phalan Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DC90AC.3030408@Sun.COM> Sender: Mark.Phalan@Sun.COM To: Darren J Moffat Cc: Lin Ma , Artem Kachitchkine , LSARC-ext@Sun.COM Message-id: <1239192571.4418.53.camel@zup> MIME-version: 1.0 X-Mailer: Evolution 2.24.2 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> <49DC864D.8000506@Sun.COM> <1239190755.4418.40.camel@zup> <49DC90AC.3030408@Sun.COM> Status: RO Content-Length: 1908 On Wed, 2009-04-08 at 12:55 +0100, Darren J Moffat wrote: > Mark Phalan wrote: > > > 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. > > gksu on OpenSolaris has been modified (though strangely the man page > doesn't talk about this - I'll file a man page bug) to first look to see > if the user has an RBAC profile for the command being run if it does > then it uses pfexec(1). > > If the user doesn't have a direct RBAC profile entry for the command but > the user can assume a role that does have an RBAC profile entry then > gksu prompts for the role password. Failing all that then gksu prompts > for the root password (which given gksu is really using su(1M) will fail > it root is a role that the user can't assume). > > For example, I created the "Desktop CD User" profile and assign it as > the case defines it to "CONSOLE_USER" in policy.conf and have an entry > for rhythmbox with privs=sys_devices in exec_attr. I then used gksu to > start up rhythmbox and we see: > > islay:pts/16$ gksu /usr/bin/rhythmbox > islay:pts/16$ ppriv $(pgrep rhythmbox) > 27049: /usr/lib/rhythmbox-metadata unix:tmpdir=/tmp > flags = > E: basic,sys_devices > I: basic,sys_devices > P: basic,sys_devices > L: all > 27037: /usr/bin/rhythmbox > flags = > E: basic,sys_devices > I: basic,sys_devices > P: basic,sys_devices > L: all > islay:pts/16$ pcred $(pgrep rhythmbox) > 27049: e/r/suid=101 e/r/sgid=10 > 27037: e/r/suid=101 e/r/sgid=10 > > Ok, that makes a lot more sense. Thanks for the explanation. -M From Lin.Ma@sun.com Wed Apr 8 06:02:46 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38D2jUh025047 for ; Wed, 8 Apr 2009 06:02:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n38D2h01018055 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 14:02:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00G059KJ4B00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 06:02:43 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00FB69KI3N10@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 06:02:43 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n38D2gwX029910 for ; Wed, 08 Apr 2009 13:02:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS003009903700@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 14:02:42 +0100 (BST) Received: from [192.168.1.101] ([unknown] [123.116.121.69]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS00BNU9KE4D70@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 14:02:41 +0100 (BST) Date: Wed, 08 Apr 2009 21:02:32 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DC90AC.3030408@Sun.COM> Sender: Lin.Ma@sun.com To: Darren J Moffat Cc: Mark Phalan , Artem Kachitchkine , LSARC-ext@sun.com Message-id: <49DCA068.2010408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> <49DC864D.8000506@Sun.COM> <1239190755.4418.40.camel@zup> <49DC90AC.3030408@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1904 Hi Darren, I don't know why you dislike pfexec script so much :-) , I just think after I move brasero.bin to /usr/lib/brasero, /usr/bin looks clean. I have a suggestion before Solaris provides runtime upgrade privileges methods. Since more and more applications will probably depend on pfexec, create the following directory structure (use brasero as example), /usr/bin/brasero link to /usr/lib/pfexec_dependent_base_dir/pfexec_wrap, the real brasero binary is delivered to /usr/lib/pfexec_dependent_base_dir/bin/, pfexec_wrap is a script to run pfexec /usr/lib/pfexec_dependent_base_dir/bin/* $*. If it is not acceptable, see my following revision of this case. >> 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. > > gksu on OpenSolaris has been modified (though strangely the man page > doesn't talk about this - I'll file a man page bug) to first look to > see if the user has an RBAC profile for the command being run if it > does then it uses pfexec(1). Yes, gksu has been modified, so this solution is acceptable to me. Revised the spec like: 1) continue using gksu through panel menu, 2) keep the following settings and updated to not use pfexec script: prof_attr: Desktop CD User:::Access CD for desktop user: Console User::::profiles=Desktop CD User exec_attr: Desktop CD User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices If users want to run brasero from a terminal, they have to explicitly use gksu to load it. Any /usr/lib/libbrasero-media.so consumer applications also require gksu. lin From Brian.Cameron@sun.com Wed Apr 8 12:57:15 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n38JvFw3019224 for ; Wed, 8 Apr 2009 12:57:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n38JvF9o018163 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 8 Apr 2009 12:57:15 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHS00B07SREOQ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Wed, 08 Apr 2009 12:57:14 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHS00APJSRCIN20@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Wed, 08 Apr 2009 12:57:13 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n38JvCsN028352 for ; Wed, 08 Apr 2009 19:57:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHS00L00S71OW00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Wed, 08 Apr 2009 13:57:12 -0600 (MDT) Received: from [10.0.0.10] ([unknown] [24.32.67.166]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHS009RWSR1TJA0@mail-amer.sun.com>; Wed, 08 Apr 2009 13:57:02 -0600 (MDT) Date: Wed, 08 Apr 2009 14:57:03 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> Sender: Brian.Cameron@sun.com To: John Fischer Cc: LSARC-ext@sun.com, Lin.Ma@sun.com Message-id: <49DD018F.8050802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090323 Thunderbird/3.0b2 Status: RO Content-Length: 7848 Due to the discussion, Lin has agreed to provide an updated proposal which will address the concerns raised. As agreed at the last LSARC meeting, the timeout has been extended to April 17th to give time to address these issues, and since John Fischer is on vacation. Thanks, Brian On 03/27/09 13:01, John Fischer wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Update to Brasero 2.25.x > 1.2. Name of Document Author/Supplier: > Author: Lin Ma > 1.3 Date of This Document: > 27 March, 2009 > 4. Technical Description > 1. Introduction > 1.1. Project/Component Working Name: > > Update to Brasero 2.25.x > > 1.2. Name of Document Author/Supplier: > > Lin Ma > > 1.3. Date of This Document: > > Mar/05/09 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: > > Solaris PAC > > 1.4.2. The ARC(s) you expect to review your project: > > LSARC > > 1.4.3. The Director/VP who is "Sponsoring" this project: > > robert.odea@sun.com > > 1.4.4. The name of your business unit: > > OPG / OpenSource > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@Sun.COM > 1.5.2. Responsible Engineer: lin.ma@Sun.COM > 1.5.3. Marketing Manager: glynn.foster@sun.com > 1.5.4. Interest List: desktop-discuss@opensolaris.org > > 4. Technical Description: > > 4.1. Details: > > Brasero is a application to burn CD/DVD for the Gnome Desktop. > It is designed to be as simple as possible and has some unique > features to enable users to create their discs easily and quickly. > > Instead of using gksu as described in LSARC 2008/548, this version > changes the method to acquire privileges. > > Brasero makes use of the profile 'Console User' so that it is only > available to the console user who is the default owner of scsi > devices. It delivers brasero media library which uses uscsi(7I) to > gather devices/media information, e.g. speed, capacity, etc. Any > applications which depend on brasero media library have to handle > the required privileges or follow what brasero does. > > According to privileges(5), brasero media library needs the > following privileges to send ioctl(2) commands to scsi devices: > > - PRIV_SYS_DEVICES > > Add the following line to the file prof_attr(4) and > exec_attr(4). Make console user has 'Desktop CD User' profile by > default. The package will also deliver file /usr/bin/brasero which > is a script to run 'pfexec /usr/bin/brasero.bin' to acquire above > privileges. > > prof_attr: > Desktop CD User:::Access CD for desktop user: > Console User::::profiles=Desktop CD User > > exec_attr: > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices > > 4.2. Bug/RFE Number(s): > > 6770524 > > 4.5. Interfaces Changes: > > |---+-------------------------+-------------+-----------------------| > | | Imported | Stability | Comments | > |---+-------------------------+-------------+-----------------------| > | - | GKsu | Uncommitted | LSARC 2006/348 GTK+ | > | | | | Authorisation Library | > |---+-------------------------+-------------+-----------------------| > | + | /usr/bin/pfexec | Committed | PSARC 2002/188 | > |---+-------------------------+-------------+-----------------------| > | + | /etc/security/exec_attr | Committed | | > |---+-------------------------+-------------+-----------------------| > > |---+----------------------------------------+---------------+---------------| > | | Exported | Stability | Comments | > |---+----------------------------------------+---------------+---------------| > | ! | /usr/bin/brasero.bin | Volatile | Binary | > |---+----------------------------------------+---------------+---------------| > | + | /usr/bin/brasero | Volatile | Script | > |---+----------------------------------------+---------------+---------------| > | ! | All brasero backends | Private | Brasero | > | | /usr/lib/brasero/plugins/*.so | | backends | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/libbrasero-media.so | Consolidation | Brasero media | > | | | Private | library [1] | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/pkgconfig/libbrasero-media.pc | Consolidation | | > | | | Private | | > |---+----------------------------------------+---------------+---------------| > | + | /usr/lib/nautilus/extensions-2.0/ | Consolidation | Nautilus | > | | libnautilus-brasero-extension.so | Private | extension | > |---+----------------------------------------+---------------+---------------| > | ! | SUNWgnome-cd-burner | Uncommitted | Package | > | ! | SUNWgnome-cd-burner-root | Uncommitted | name | > | + | SUNWgnome-cd-burner-devel | Uncommitted | changes | > |---+----------------------------------------+---------------+---------------| > | - | SUNWbrasero | Obsolete | Old package | > | - | SUNWbrasero-root | Uncommitted | names these | > | | | | will be | > | | | | removed | > |---+----------------------------------------+---------------+---------------| > > [1] The library for accessing scsi devices requires 'sys_devices'. It > could be linked to other desktop applications. > > [2] The first column within the interface tables refers to the following: > '+' means that the interface was added > '-' means that the interface was removed > '!' means that the interface was changed > > 4.7. Admin/Config Impact: > > Since brasero is for console users by default, it doesn't take > care of the ownership of a scsi device. If the admin wants to give > non-console users the ability to use brasero, he has to append > privilege 'file_dac_read' to line 'Desktop CD User/brasero' in > exec_attr, like: > > Desktop CD User:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices,file_dac_read > > 4.11. Security Impact: > > A not Privilege Awareness(NPA) command excuted by the user (who has > 'Primary Administrator' profile) with pfexec(1) will be matched > the line: > > Primary Administrator:suser:cmd:::*:uid=0;gid=0 > > which will become a root process. The result is the reason of > CR#6749728 eject function doesn't work. > > A temporary solution is to add the following line to exec_attr(4): > > Primary Administrator:solaris:cmd:::/usr/bin/brasero.bin:privs=sys_devices > > 5. Reference Documents: > > LSARC 2008/548 Brasero 0.8.x > > RFE - 6770524 > > More information about Brasero can be found at these locations: > > http://www.gnome.org/projects/brasero > http://www.gnomefiles.org/app.php/Brasero > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > JDS - Desktop > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From Lin.Ma@sun.com Wed Apr 8 22:59:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n395xO2E008668 for ; Wed, 8 Apr 2009 22:59:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n395xNok016806 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 9 Apr 2009 06:59:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHT00A03KMZI500@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 23:59:23 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHT007U6KMYNU40@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 08 Apr 2009 23:59:22 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n395xLCe012313 for ; Thu, 09 Apr 2009 05:59:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHT00L00KDBME00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 09 Apr 2009 06:59:21 +0100 (BST) Received: from [129.158.217.127] ([unknown] [129.158.217.127]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHT00GRHKMVBU20@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 09 Apr 2009 06:59:21 +0100 (BST) Date: Thu, 09 Apr 2009 13:59:13 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DC864D.8000506@Sun.COM> Sender: Lin.Ma@sun.com To: Darren J Moffat Cc: Artem Kachitchkine , LSARC-ext@sun.com Message-id: <49DD8EB1.1020207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49D2556F.6050905@sun.com> <49D29E80.9030301@sun.com> <49D32B05.3020103@Sun.COM> <49D3B8DB.9010205@sun.com> <49D4239D.9060003@Sun.COM> <49DC19EA.4030002@Sun.COM> <49DC864D.8000506@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 437 Hi Darren, > 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 point 3) is still existed. gksu uses getexecuser, and I think the first profile will be selected. Run "gksu id" can verify that. Thanks, lin From Brian.Cameron@sun.com Tue Apr 14 01:22:59 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3E8MwwZ003331 for ; Tue, 14 Apr 2009 01:22:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3E8MupE008613 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 14 Apr 2009 01:22:58 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI30020J0M91G00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 02:22:57 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI300GBA0M9CSA0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 02:22:57 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3E8Mvx6022763 for ; Tue, 14 Apr 2009 08:22:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI300B00045RV00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 02:22:57 -0600 (MDT) Received: from [10.0.0.13] ([unknown] [24.32.67.166]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI300LCK0M80OF0@mail-amer.sun.com>; Tue, 14 Apr 2009 02:22:56 -0600 (MDT) Date: Tue, 14 Apr 2009 03:23:02 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49DD018F.8050802@sun.com> Sender: Brian.Cameron@sun.com To: Brian Cameron Cc: John Fischer , LSARC-ext@sun.com, Lin.Ma@sun.com Message-id: <49E447E6.9080406@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_wYbTf7MAvM1I0zkcvqiAzw)" X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090406 Thunderbird/3.0b2 Status: RO Content-Length: 6647 This is a multi-part message in MIME format. --Boundary_(ID_wYbTf7MAvM1I0zkcvqiAzw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT LSARC: Lin Ma provided me with an updated proposal for Brasero which he believes will address the issues raised in this case so far. See attached. Thanks, Brian --Boundary_(ID_wYbTf7MAvM1I0zkcvqiAzw) Content-type: text/plain; name=brasero-onepager.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=brasero-onepager.txt 1. Introduction 1.1. Project/Component Working Name: Update to Brasero 2.25.x 1.2. Name of Document Author/Supplier: Lin Ma 1.3. Date of This Document: Mar/05/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: robert.odea@sun.com 1.4.4. The name of your business unit: OPG / OpenSource 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@Sun.COM 1.5.2. Responsible Engineer: lin.ma@Sun.COM 1.5.3. Marketing Manager: glynn.foster@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 4. Technical Description: 4.1. Details: Refer to LSARC 2008/548 for background on brasero. This case modifies the way brasero works with RBAC. Brasero makes use of the profile Console User' so that it is only available to the console user who is the default owner of scsi devices. It delivers brasero media library which uses uscsi(7I) to gather devices/media information, e.g. speed, capacity, etc. Any applications which depend on brasero media library have to handle the required privileges or follow what brasero does. According to privileges(5), brasero media library needs the following privileges to send ioctl(2) commands to scsi devices: - PRIV_SYS_DEVICES Add the following line to the file prof_attr(4) and exec_attr(4). Make console user has 'Desktop CD User' profile by default. prof_attr: Desktop CD User:::Access CD for desktop user: Console User::::profiles=Desktop CD User exec_attr: Desktop CD User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices If HAL team is about to add better fine-grained privileges "uscsi_full" and "uscsi_user" for scsi access, brasero's configuration will change to using the new privileges once they become available. 4.2. Bug/RFE Number(s): 6770524 4.5. Interfaces Changes: |---+-------------------------+-------------+-----------------------| | | Imported | Stability | Comments | |---+-------------------------+-------------+-----------------------| | + | /etc/security/exec_attr | Committed | | |---+-------------------------+-------------+-----------------------| | + | /etc/security/prof_attr | Committed | | |---+-------------------------+-------------+-----------------------| |---+----------------------------------------+---------------+---------------| | | Exported | Stability | Comments | |---+----------------------------------------+---------------+---------------| | ! | All brasero backends | Private | Brasero | | | /usr/lib/brasero/plugins/*.so | | backends | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/libbrasero-media.so | Consolidation | Brasero media | | | | Private | library [1] | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/pkgconfig/libbrasero-media.pc | Consolidation | | | | | Private | | |---+----------------------------------------+---------------+---------------| | + | /usr/lib/nautilus/extensions-2.0/ | Consolidation | Nautilus | | | libnautilus-brasero-extension.so | Private | extension | |---+----------------------------------------+---------------+---------------| | ! | SUNWgnome-cd-burner | Uncommitted | Package | | ! | SUNWgnome-cd-burner-root | Uncommitted | name | | + | SUNWgnome-cd-burner-devel | Uncommitted | changes | |---+----------------------------------------+---------------+---------------| | - | SUNWbrasero | Obsolete | Old package | | - | SUNWbrasero-root | Uncommitted | names | |---+----------------------------------------+---------------+---------------| [1] The library libbrasero-media.so for accessing scsi devices requires 'sys_devices'. It could be linked with other desktop applications. The consumer applications of this library require gksu to obtain the privilege. 4.7. Admin/Config Impact: Since brasero is only available for console users by default, it doesn't take care of the ownership of a scsi device. If the admin wants to give non-console users the ability to use brasero, he has to append privilege 'file_dac_read' to line 'Desktop CD User/brasero' in exec_attr, like: Desktop CD User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices,file_dac_read 4.11. Security Impact: A not Privilege Awareness(NPA) command excuted by the user (who has 'Primary Administrator' profile) with gksu(1) will be matched the line: Primary Administrator:suser:cmd:::*:uid=0;gid=0 which will become a root process. This causes issue found in CR#6749728 eject function doesn't work. A workaround is to add the following line to exec_attr(4): Primary Administrator:solaris:cmd:::/usr/bin/brasero:privs=sys_devices A normal user who doesn't have "Desktop CD User" profile will be prompted by inputing root password, if the password is correct, then brasero process becomes a root process and will have the same problem. There is no solution for this case. 5. Reference Documents: LSARC 2008/548 Brasero 0.8.x PSARC 1999/214 Removable Media Support PSARC 2000/490 libsmedia server PSARC 2001/771 libsmedia Enhancement RFE - 6770524 More information about Brasero can be found at these locations: http://www.gnome.org/projects/brasero http://www.gnomefiles.org/app.php/Brasero --Boundary_(ID_wYbTf7MAvM1I0zkcvqiAzw)-- From Darren.Moffat@sun.com Tue Apr 14 06:31:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3EDVhaS004601 for ; Tue, 14 Apr 2009 06:31:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3EDVf76029024 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 14 Apr 2009 21:31:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI300J09EWTZ300@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 06:31:41 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI300D1BEWRCV70@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 06:31:40 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3EDVdXm024149 for ; Tue, 14 Apr 2009 13:31:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI300600EDX6Y00@fe-emea-09.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 14 Apr 2009 14:31:39 +0100 (BST) Received: from [129.156.173.251] ([unknown] [129.156.173.251]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI300FI3EVZ5SB0@fe-emea-09.sun.com>; Tue, 14 Apr 2009 14:31:11 +0100 (BST) Date: Tue, 14 Apr 2009 14:31:11 +0100 From: Darren J Moffat Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49E447E6.9080406@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: John Fischer , LSARC-ext@sun.com Message-id: <49E4901F.4050607@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090223) Status: RO Content-Length: 1658 Section 4.11 Security Impact The interaction between "Primary Administrator" and "Console User" RBAC profiles is unfortunate. This basically says to me that this doesn't actually work in a useful way given how OpenSolaris system initial user having having "Primary Administrator". In my opinion that is a bad config but it wasn't one the ARC was asked to review nor it it for this case to fix (I believe the issue is being discussed elsewhere though). IIRC it was done before "Console User" existed. However the particular problem it causes 6749728 seems to be in scope for this case to resolve though and I think to approve this architecture it needs to be solved, or this case needs to be dependent on a case (or some other commitment) that we stop assigning "Primary Administrator" to the default user account. The workaround of modifying the "Primary Administrator" profile isn't acceptable and will actually cause different problems. Please do not document the advice that the "Desktop CD User" be modified by an end system admin. Instead document that they should create their own profile and assign that to users instead. The reasons for this is that we do not have a good upgrade story for what happens when the system admin modifies profiles we deliver - it is made worse by the current lack of any upgrade of these in OpenSolaris IPS based systems - and is further complicated by the fact that the entries could be in a remote nameservice. On the naming the "Desktop CD User" profile name should probably be CD/DVD/BlueRay which makes me thing it really should be "Desktop Removable Media User" -- Darren J Moffat From Brian.Cameron@sun.com Tue Apr 14 09:43:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3EGhB0l005427 for ; Tue, 14 Apr 2009 09:43:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3EGh8sS004420 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 14 Apr 2009 09:43:11 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI30051JNRXU100@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 14 Apr 2009 10:43:09 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI300EW3NRWR2B0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 14 Apr 2009 10:43:08 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3EGh8if011312 for ; Tue, 14 Apr 2009 16:43:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI300F00M5XHD00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 14 Apr 2009 10:43:08 -0600 (MDT) Received: from [10.0.0.10] ([unknown] [24.32.67.166]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI300M4NNRO3C80@mail-amer.sun.com>; Tue, 14 Apr 2009 10:43:03 -0600 (MDT) Date: Tue, 14 Apr 2009 11:43:06 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49E4901F.4050607@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: John Fischer , LSARC-ext@sun.com Message-id: <49E4BD1A.7010903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090406 Thunderbird/3.0b2 Status: RO Content-Length: 1275 Darren: > However the particular problem it causes 6749728 seems to be in scope > for this case to resolve though and I think to approve this architecture > it needs to be solved, or this case needs to be dependent on a case (or > some other commitment) that we stop assigning "Primary Administrator" to > the default user account. The workaround of modifying the "Primary > Administrator" profile isn't acceptable and will actually cause > different problems. > > Please do not document the advice that the "Desktop CD User" be modified > by an end system admin. Instead document that they should create their > own profile and assign that to users instead. Should we create a profile for them to use out-of-the-box, but just not assign it to any users? > The reasons for this is > that we do not have a good upgrade story for what happens when the > system admin modifies profiles we deliver - it is made worse by the > current lack of any upgrade of these in OpenSolaris IPS based systems - > and is further complicated by the fact that the entries could be in a > remote nameservice. Would it be recommended that programs like brasero pop-up a dialog window on failure to explain to the user the recommended way to configure the system to avoid bug #6749728? Brian From Lin.Ma@sun.com Wed Apr 15 02:22:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3F9MYxs017269 for ; Wed, 15 Apr 2009 02:22:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3F9MQk3007112 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 15 Apr 2009 10:22:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI400G0FY1JKI00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 15 Apr 2009 03:22:31 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI400FIMY1IZH00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 15 Apr 2009 03:22:31 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3F9MUEB022735 for ; Wed, 15 Apr 2009 09:22:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI400100XX6EZ00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 15 Apr 2009 10:22:30 +0100 (BST) Received: from [129.158.217.127] ([unknown] [129.158.217.127]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI40070QY1AE300@fe-emea-09.sun.com>; Wed, 15 Apr 2009 10:22:25 +0100 (BST) Date: Wed, 15 Apr 2009 17:22:19 +0800 From: Lin Ma Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49E4901F.4050607@Sun.COM> Sender: Lin.Ma@sun.com To: Darren J Moffat Cc: Brian Cameron , John Fischer , LSARC-ext@sun.com Message-id: <49E5A74B.4000304@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2881 Hi Darren, Darren J Moffat wrote: > Section 4.11 Security Impact > > The interaction between "Primary Administrator" and "Console User" > RBAC profiles is unfortunate. This basically says to me that this > doesn't actually work in a useful way given how OpenSolaris system > initial user having having "Primary Administrator". In my opinion > that is a bad config but it wasn't one the ARC was asked to review nor > it it for this case to fix (I believe the issue is being discussed > elsewhere though). IIRC it was done before "Console User" existed. Agree. > However the particular problem it causes 6749728 seems to be in scope > for this case to resolve though and I think to approve this > architecture it needs to be solved, or this case needs to be dependent > on a case (or some other commitment) that we stop assigning "Primary > Administrator" to the default user account. The workaround of > modifying the "Primary Administrator" profile isn't acceptable and > will actually cause different problems. I personally prefer the later, make this case depend on a case like "stop assigning 'Primary Administrator'", because gnome applications can obtain root privileges easier with that profile. It isn't good. However it looks like a long-term goal. So I think I should try to fix 6749728. My request is 6749728 is very complex, I hope I can get approval and integrate Brasero first and fix that bug later. I will remove the workaround from this case, update it like: --------------- A not Privilege Awareness(NPA) command excuted by the user (who has 'Primary Administrator' profile) with gksu(1) will be matched the line: Primary Administrator:suser:cmd:::*:uid=0;gid=0 which will become a root process. This causes issue found in CR#6749728 eject function doesn't work. --------------- Is it OK? > > Please do not document the advice that the "Desktop CD User" be > modified by an end system admin. Instead document that they should > create their own profile and assign that to users instead. The > reasons for this is that we do not have a good upgrade story for what > happens when the system admin modifies profiles we deliver - it is > made worse by the current lack of any upgrade of these in OpenSolaris > IPS based systems - and is further complicated by the fact that the > entries could be in a remote nameservice. OK, I will document that "If system admin wants give users who do not have 'Console User' profile the ability to use Brasero, he need to create a new profile to the users and assign a proper privileges to Brasero in that profile." Is it OK? > On the naming the "Desktop CD User" profile name should probably be > CD/DVD/BlueRay which makes me thing it really should be "Desktop > Removable Media User" While I'm not a native speaker, so I will always agree on the name changes. lin From John.Fischer@sun.com Thu Apr 16 14:27:46 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3GLRk4w009273 for ; Thu, 16 Apr 2009 14:27:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3GLRQY8000548 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 16 Apr 2009 22:27:45 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI70020PQA6QR00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 16 Apr 2009 15:27:42 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI7000XLQA62R10@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 16 Apr 2009 15:27:42 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3GLRg8I005960 for ; Thu, 16 Apr 2009 21:27:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI700800PJ84O00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 16 Apr 2009 15:27:41 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI7000UTQA4VYE0@mail-amer.sun.com>; Thu, 16 Apr 2009 15:27:40 -0600 (MDT) Date: Thu, 16 Apr 2009 14:26:41 -0700 From: John Fischer Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49E5A74B.4000304@Sun.COM> Sender: John.Fischer@sun.com To: Lin Ma Cc: Darren J Moffat , Brian Cameron , John Fischer , LSARC-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <49E7A291.5070704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> <49E5A74B.4000304@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3053 Darren, Have your issues be sufficiently addressed? Thanks, John Lin Ma wrote: > Hi Darren, > > Darren J Moffat wrote: >> Section 4.11 Security Impact >> >> The interaction between "Primary Administrator" and "Console User" >> RBAC profiles is unfortunate. This basically says to me that this >> doesn't actually work in a useful way given how OpenSolaris system >> initial user having having "Primary Administrator". In my opinion >> that is a bad config but it wasn't one the ARC was asked to review nor >> it it for this case to fix (I believe the issue is being discussed >> elsewhere though). IIRC it was done before "Console User" existed. > Agree. > >> However the particular problem it causes 6749728 seems to be in scope >> for this case to resolve though and I think to approve this >> architecture it needs to be solved, or this case needs to be dependent >> on a case (or some other commitment) that we stop assigning "Primary >> Administrator" to the default user account. The workaround of >> modifying the "Primary Administrator" profile isn't acceptable and >> will actually cause different problems. > I personally prefer the later, make this case depend on a case like > "stop assigning 'Primary Administrator'", because gnome applications can > obtain root privileges easier with that profile. It isn't good. However > it looks like a long-term goal. So I think I should try to fix 6749728. > > My request is 6749728 is very complex, I hope I can get approval and > integrate Brasero first and fix that bug later. I will remove the > workaround from this case, update it like: > --------------- > > A not Privilege Awareness(NPA) command excuted by the user (who has > 'Primary Administrator' profile) with gksu(1) will be matched > the line: > > Primary Administrator:suser:cmd:::*:uid=0;gid=0 > > which will become a root process. This causes issue found in > CR#6749728 eject function doesn't work. > > --------------- > Is it OK? >> >> Please do not document the advice that the "Desktop CD User" be >> modified by an end system admin. Instead document that they should >> create their own profile and assign that to users instead. The >> reasons for this is that we do not have a good upgrade story for what >> happens when the system admin modifies profiles we deliver - it is >> made worse by the current lack of any upgrade of these in OpenSolaris >> IPS based systems - and is further complicated by the fact that the >> entries could be in a remote nameservice. > OK, I will document that "If system admin wants give users who do not > have 'Console User' profile the ability to use Brasero, he need to > create a new profile to the users and assign a proper privileges to > Brasero in that profile." Is it OK? > >> On the naming the "Desktop CD User" profile name should probably be >> CD/DVD/BlueRay which makes me thing it really should be "Desktop >> Removable Media User" > While I'm not a native speaker, so I will always agree on the name changes. > > lin From Darren.Moffat@sun.com Mon Apr 20 02:34:31 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3K9YUU9026060 for ; Mon, 20 Apr 2009 02:34:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3K9YTAU002597 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 02:34:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00I037XIO000@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 02:34:30 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00FT77XHZP30@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 02:34:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3K9YTJq009173 for ; Mon, 20 Apr 2009 09:34:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE008007CTQ300@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 10:34:29 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00KWW7X1TEE0@fe-emea-10.sun.com>; Mon, 20 Apr 2009 10:34:14 +0100 (BST) Date: Mon, 20 Apr 2009 10:34:13 +0100 From: Darren J Moffat Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49E7A291.5070704@sun.com> Sender: Darren.Moffat@sun.com To: John.Fischer@sun.com Cc: Lin Ma , Brian Cameron , John Fischer , LSARC-ext@sun.com Message-id: <49EC4195.2080009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> <49E5A74B.4000304@Sun.COM> <49E7A291.5070704@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 380 John Fischer wrote: > Darren, > > Have your issues be sufficiently addressed? Not really but I don't think there is anything further this case can do. I also don't seen any value in derailing for the purpose of opinion writing since the issue is already known and the teams responsible in contact about it. This case can go forward as last specified. -- Darren J Moffat From John.Fischer@sun.com Tue Apr 21 06:02:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LD2qY5003169 for ; Tue, 21 Apr 2009 06:02:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3LD2mJx019276 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 21 Apr 2009 21:02:51 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG0060ZC8QDA00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 21 Apr 2009 07:02:50 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00IWTC8OK260@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 21 Apr 2009 07:02:48 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LD2msV025280 for ; Tue, 21 Apr 2009 13:02:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIG00N00C703P00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 21 Apr 2009 07:02:48 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIG00K97C8OBE90@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 21 Apr 2009 07:02:48 -0600 (MDT) Date: Tue, 21 Apr 2009 06:01:47 -0700 From: John Fischer Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49EC4195.2080009@Sun.COM> Sender: John.Fischer@sun.com To: Darren J Moffat Cc: Lin Ma , LSARC-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <49EDC3BB.4090506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> <49E5A74B.4000304@Sun.COM> <49E7A291.5070704@sun.com> <49EC4195.2080009@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 599 All, With Darren's issues with this case having been addressed within the latest specification and the timer having expired I am closing this case approved. Thanks, John Darren J Moffat wrote: > John Fischer wrote: >> Darren, >> >> Have your issues be sufficiently addressed? > > Not really but I don't think there is anything further this case can do. > I also don't seen any value in derailing for the purpose of opinion > writing since the issue is already known and the teams responsible in > contact about it. This case can go forward as last specified. > > -- > Darren J Moffat > From Brian.Cameron@sun.com Mon Apr 27 18:50:22 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3S1oL0D000072 for ; Mon, 27 Apr 2009 18:50:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3S1oJhp013797 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 27 Apr 2009 19:50:21 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIS00315FRWXL00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 18:50:20 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIS003H5FRUEC30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 18:50:18 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3S1oIkx016207 for ; Tue, 28 Apr 2009 01:50:18 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIS00B00FPQSF00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 19:50:18 -0600 (MDT) Received: from [192.168.1.70] ([unknown] [189.137.184.97]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIS0069NFRS6A20@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 19:50:17 -0600 (MDT) Date: Mon, 27 Apr 2009 20:50:18 -0500 From: Brian Cameron Subject: Re: Update to Brasero 2.25.x [LSARC/2009/201 FastTrack timeout 04/03/2009] In-reply-to: <49EDC3BB.4090506@sun.com> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: Darren J Moffat , LSARC-ext@sun.com Message-id: <49F660DA.50601@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_HL6R+wAjhpwzOOm01jrB2w)" X-PMX-Version: 5.4.1.325704 References: <200903271801.n2RI1FiM002055@paravon.sfbay.sun.com> <49DD018F.8050802@sun.com> <49E447E6.9080406@sun.com> <49E4901F.4050607@Sun.COM> <49E5A74B.4000304@Sun.COM> <49E7A291.5070704@sun.com> <49EC4195.2080009@Sun.COM> <49EDC3BB.4090506@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b3pre) Gecko/20090420 Thunderbird/3.0b2 Status: RO Content-Length: 1839 This is a multi-part message in MIME format. --Boundary_(ID_HL6R+wAjhpwzOOm01jrB2w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT All: One minor change to the LSARC 2009/201 case. In Lin Ma's discussions with Darren Moffat, they agreed that "Desktop Removable Media User" is better than "Desktop CD User". So the case materials were updated to reflect this minor change. The difference is shown in the attached diff file. Brian > With Darren's issues with this case having been addressed within the > latest specification and the timer having expired I am closing this case > approved. > > Thanks, > > John > > Darren J Moffat wrote: >> John Fischer wrote: >>> Darren, >>> >>> Have your issues be sufficiently addressed? >> >> Not really but I don't think there is anything further this case can >> do. I also don't seen any value in derailing for the purpose of >> opinion writing since the issue is already known and the teams >> responsible in contact about it. This case can go forward as last >> specified. >> >> -- >> Darren J Moffat >> > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org --Boundary_(ID_HL6R+wAjhpwzOOm01jrB2w) Content-type: text/plain; name=brasero.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=brasero.diff 60,61c60,61 < Desktop CD User:::Access CD for desktop user: < Console User::::profiles=Desktop CD User --- > Desktop Removable Media User:::Access removable media for desktop user: > Console User::::profiles=Desktop Removable Media User 64c64 < Desktop CD User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices --- > Desktop Removable Media User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices --Boundary_(ID_HL6R+wAjhpwzOOm01jrB2w)--