From gww@sac.sfbay.sun.com Wed Jun 6 16:18:24 2007 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 l56NINbY026047 for ; Wed, 6 Jun 2007 16:18:24 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l56NGs7F004437; Thu, 7 Jun 2007 00:16:58 +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 <0JJ800805M06KD00@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 17:16:54 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ8004W2M05BP70@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 17:16:53 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l56NGqrp013143; Wed, 06 Jun 2007 16:16:52 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l56NIGkw026042; Wed, 06 Jun 2007 16:18:16 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l56NIG8U026038; Wed, 06 Jun 2007 16:18:16 -0700 (PDT) Date: Wed, 06 Jun 2007 16:18:16 -0700 (PDT) From: Gary Winiger Subject: 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-ext@sun.com Cc: ashish.joshi@sun.com Message-id: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 12811 I'm sponsoring this Fast Track for Ashish Joshi. It updates PSARC/2005/691 Trusted Extensions for Device Allocation to satisfy various Trusted Extensions related RFEs for correctly mounting removable media and for SunRay running in a Trusted Extensions environment. A patch release binding is requested. This project is intended to be backported to a Solaris 10 update. The interface taxonomy of PSARC/2005/691 is updated to the current taxonomy by mapping the previously Evolving interfaces to Uncommitted and previously Unstable (which is the human readable output) to Not-An-Interface. Evolving to Uncommitted is requested in light of a future planned but, not yet scheduled, project to integrate the device allocation functionality under Tamarack: Removable Media Enhancements in Solaris (PSARC/2005/399) for all of the Solaris configurations. Updated full and diff marked man pages are in the case directory. '~' in the first column represent missing changes from 2005/691. '+', '-', and '|' represent changes for this case. The timer is set for 13 June 2007 Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: =========== PSARC/2005/691 Trusted Extensions for Device Allocation added label support to the Device Allocation functionality already in Solaris (as part of the BSM project done in the SunOS 5.3 time frame and still not fully ARCed). Device Allocation is designed to meet confidentiality, object reuse and accountability requirements for non-media (e.g., audio, printing) and removable media (e.g., floppy, cdrom, usb disk) devices. This is largely accomplished by disabling vold(1M), hald(1M), logindevperm(4) and replacing the functionality with the device_allocate(4) and device_maps(4) databases, and the allocate(1), deallocate(1) and list_devices(1) CLIs. Non-media and removable media devices are not accessible to users until "allocated." Devices don't become available for other user access until "deallocated." Allocation consists of verifying if the user is authorized to use the device, then changing its ownership and permissions to exclusive use of the user and finally auditing. Deallocation removes the ownership, clears the permissions, runs a device_clean(5) script/program to remove any remaining state or media (object reuse) and audits. PSARC/2005/691 added to allocate(1) label checking and running device_clean, which calls rmmount(1M) where appropriate to mount media. Also added were add_allocatable(1M) and remove_allocatable(1M) to manage device_allocate(4) and device_maps(4). Depending on the future projects to integrate with Tamarack, they may not survive. Problem 1: ========== allocate/deallocate/list_devices(1) have a number of undocumented exit codes. While these should have been documented as part of the SunOS 5.3 putback or PSARC/2005/691, they never were. It turns out SunRay is relying on one of these values to determine if it should retry an failed operation. Solution 1: ========== Document the return values for allocate/deallocate/list_devices(1) on the man page. Since this has not been documented before and there appear to be no other consumers, the project team proposes: EXIT STATUS The following exit values are returned: | 0 Success. + 20 No entry for specified device. + Other values General error Problem 2: ========== The existing exit values from device_clean(5) (missing from the current man page -- see case directory) are insufficient to determine the type of outcome for mounting removable media. allocate/deallocate need to react differently to mount/umount success/failure than general success/failure. A failed mount should not place the device in an error state. The user should be allowed to proceed, perhaps to format and mount the device. Solution 2: =========== Add new exit values to device_clean. This allows allocate/deallocate to correctly deal with setting up devices mount based on the mount status. device_clean(5): ~~~~~~~~~~~~~~~~~~~~~~ EXIT VALUES ~ The following exit values are returned: ~ ~ 0 Successful completion. ~ ~ 1 An error. Caller may place device in error ~ state. ~ ~ 2 A system error. Caller may place device in error ~ state. ~ + On a system configured with Trusted Extensions, the + following additional exit values are returned: + + 3 Mounting of device failed. Caller shall not + place device in error state. + + 4 Mounting of device succeeded. Problem 3: ========== The existing device type values of device_allocate(4) are insufficient to allow for proper operation with SunRay. SunRay operation needs to be able to know about and manage all the devices associated with a particular SunRay session, orthogonally to the existing device type. When a SunRay session terminates, it needs to atomically clean up and know it is done. When the device management GUI needs to list the devices associated with the SunRay session, it needs to do so orthogonally to the type of device. Furthermore, SunRay needs to keep track of which allocated devices are associated with which display. (When a local/console session terminates, devices remain allocated unless the user deallocated them.) Solution 3: =========== Add a new key word, "class" in device_allocate(4) (key words were introduced in PSARC/2005/691, but are missing from the current man page -- see case directory) to the existing key words to distinguish a class of devices. Add a new key word, "xdpy" in device_allocate(4) to the existing key words to store an X Display name. Both new key words are generic and are not restricted to SunRay operation. SunRay is the first identified consumer. add_allocatable(1M) and remove_allocatable(1M) are used to update device_allocate(4). device_allocate(4): ~~~~~~~~~~~~~~~~~~~~~~ DESCRIPTION The device_allocate file contains mandatory access control information about each physical device. Each device is represented by a one line entry of the form: ~ device-name;device-type;reserved1;reserved2;auths;device-exec device-type This is an arbitrary ASCII string naming the generic device type. This field identifies and groups together devices of like type. This field contains no embedded white space ~ or non-printable characters. The following ~ types of devices are currently managed by the ~ system: audio, sr (represents CDROM drives), ~ fd (represents floppy drives), st (represents ~ tape drives), rmdisk (removable media devices) ~ reserved1 On systems configured with Trusted Extensions, ~ this field stores a colon-separated (:) list ~ of key-value pairs that describe device ~ allocation attributes used in Trusted ~ Extensions. Zero or more keys may be ~ specified. The following keys are currently ~ interpreted by Trusted Extensions systems: ~ minlabel Specifies the minimum label at ~ which device can be allocated. ~ Default value is admin_low. ~ maxlabel Specifies the maximum label at ~ which device can be allocated. ~ Default value is admin_high. ~ zone Specifies the name of the zone ~ in which device is currently ~ allocated. + class Specifies a logical grouping + of devices. For e.g., all Sun + Ray devices of all device types. + There is no default class. + xdpy Specifies the X Display name. + This is used to identify devices + associated with that X session. + There is no default xdpy value. add_allocatable(1M): ~~~~~~~~~~~~~~~~~~~~~~ OPTIONS -o key=value Accepts a string of colon-separated key=value pairs for a device that is speci- fied with -n or with devices of the type that is specified with -t. The following keys are currently interpreted by the sys- tem: minlabel The minimum label at which the dev- ice can be used. maxlabel The maximum label at which the dev- ice can be used. + class Specifies a logical grouping of + devices. For e.g., all SunRay + devices of all device types. There + no default class specified. + + xdpy Specifies the X Display name. + This is used to identify devices + associated with that X session. + There is no default xdpy value. remove_allocatable(1M): ~~~~~~~~~~~~~~~~~~~~~~ SYNOPSIS | /usr/sbin/remove_allocatable [-f] [-n name | -c dev-class] /usr/sbin/remove_allocatable [-f] [-d] -t dev-type OPTIONS + -c dev-class Removes devices that belong to dev-class. deallocate(1): ~~~~~~~~~~~~~~~~~~~~~~ SYNOPSIS | deallocate [-s] [-w] [-F] [-z zonename] + [-c dev-class | -g dev-type | device] - deallocate [-s] [-w] [-F] [-z zonename] -g dev-type deallocate [-s] [-w] [-F] [-z zonename] -I OPTIONS The following options are supported: + -c dev-class Deallocates all devices of the specified + device class. list_devices(1): ~~~~~~~~~~~~~~~~~~~~~~ SYNOPSIS list_devices [-s] [-U uid] [-z zonename] [-a] | [-l | -n | -u] [-c dev-class | device] DESCRIPTION The list_devices utility lists the allocatable devices in the system according to specified qualifications. The device and all device special files associated with the device are listed. The device argument is optional and, if | it is not present, all relevant devices are listed, unless + dev-class is present, in which case devices belonging to the + specified dev-class are listed. There is no default + dev-class. OPTIONS The following options are supported: | -l [-c dev-class | device] Lists the pathname(s) of the device special files associated with the device that are | allocatable to the current process. + If dev-class is given, lists only the files + associated with all devices of the specified + device class. | If device is given, lists only the files | associated with the specified device. | -n [-c dev-class | device] Lists the pathname(s) of device special files associated with the device that are allocat- able to the current process but are not | currently allocated. + If dev-class is given, lists only the files + associated with all devices of the specified + device class. | If device is given, lists only the files | associated with the specified device. | -u [-c dev-class | device] Lists the pathname(s) of device special files, associated with the device that are allocated to the owner of the current pro- | cess. + If dev-class is given, lists only the files + associated with all devices of the specified + device class. | If device is given, lists only the files | associated with the specified device. -U uid Uses the user ID uid instead of the real user ID of the current process when performing the list_devices operation. Only a user with the solaris.device.revoke authorization can use this option. -s Silent. Suppresses any diagnostic output. From carlsonj@phorcys.east.sun.com Thu Jun 7 05:28:58 2007 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 l57CSwsd012879 for ; Thu, 7 Jun 2007 05:28:58 -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 l57CRV42007009 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 7 Jun 2007 05:27:32 -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 <0JJ900601MLS5100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Jun 2007 05:27:28 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ900D0JMLS9290@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Jun 2007 05:27:28 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l57CRPFt029646; Thu, 07 Jun 2007 08:27:25 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l57CRPbw005401; Thu, 07 Jun 2007 08:27:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l57CRO4P005398; Thu, 07 Jun 2007 08:27:24 -0400 (EDT) Date: Thu, 07 Jun 2007 08:27:24 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, ashish.joshi@sun.com Message-id: <18023.63916.967995.441199@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> Status: RO Content-Length: 1213 Gary Winiger writes: > Evolving to Uncommitted is requested in light of a future planned but, > not yet scheduled, project to integrate the device allocation functionality > under Tamarack: Removable Media Enhancements in Solaris (PSARC/2005/399) > for all of the Solaris configurations. Does this mean that Sun Ray will need and get a contract? I don't see one in the case directory. > + On a system configured with Trusted Extensions, the > + following additional exit values are returned: > + > + 3 Mounting of device failed. Caller shall not > + place device in error state. > + > + 4 Mounting of device succeeded. This seems a little over-complicated. I would suggest returning 0 for the mount-succeeded case and adding just: 3 Allocation succeeded, but mounting failed. Media may be in unformatted state. Caller should not assume device has failed. (In other words, I don't see a difference between codes 4 and 0.) -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From ashish.joshi@sun.com Thu Jun 7 11:39:40 2007 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 l57Iddf6019408 for ; Thu, 7 Jun 2007 11:39:39 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l57Ic7JM022543; Thu, 7 Jun 2007 19:38:12 +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 <0JJA00L033RN1Y00@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 12:38:11 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA009493RM4ZE0@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 12:38:10 -0600 (MDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l57Ic9sA026358; Thu, 07 Jun 2007 11:38:09 -0700 (PDT) Received: from sun.com (vpn-129-150-19-108.SFBay.Sun.COM [129.150.19.108]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l57Ic8O04935; Thu, 07 Jun 2007 11:38:08 -0700 (PDT) Date: Thu, 07 Jun 2007 11:38:08 -0700 From: Ashish Joshi Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18023.63916.967995.441199@gargle.gargle.HOWL> To: James Carlson Cc: Gary Winiger , PSARC-ext@sun.com, rampart , Michael Bender Message-id: <46685090.9070709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030313 Status: RO Content-Length: 1806 James Carlson wrote: > Gary Winiger writes: > >>Evolving to Uncommitted is requested in light of a future planned but, >>not yet scheduled, project to integrate the device allocation functionality >>under Tamarack: Removable Media Enhancements in Solaris (PSARC/2005/399) >>for all of the Solaris configurations. > > > Does this mean that Sun Ray will need and get a contract? I don't see > one in the case directory. > Because Sun Ray is using now Uncommitted interfaces? I guess. I'll check with Gary when he's back (on Monday?). >>+ On a system configured with Trusted Extensions, the >>+ following additional exit values are returned: >>+ >>+ 3 Mounting of device failed. Caller shall not >>+ place device in error state. >>+ >>+ 4 Mounting of device succeeded. > > > This seems a little over-complicated. I would suggest returning 0 for > the mount-succeeded case and adding just: > > 3 Allocation succeeded, but mounting failed. Media may > be in unformatted state. Caller should not assume > device has failed. > > (In other words, I don't see a difference between codes 4 and 0.) > Mounting/unmounting during allocation/deallocation (done through device_clean) is done only in TX. In TX, if allocate does not mount the device (for non-mountable devices, and for mountable devices for which user opts to not mount them), allocate needs to create device nodes in the non-global zone in which the device is being allocated. So, there needs to be a distinction between general success (0) and mount success (4) because allocate needs to know that it has to create device nodes in the non-global zone after general success from device_clean, but not after mount success from device_clean. - Ashish. From carlsonj@phorcys.east.sun.com Thu Jun 7 13:43:46 2007 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 l57KhjJt022122 for ; Thu, 7 Jun 2007 13:43:46 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l57KgCdt004316; Thu, 7 Jun 2007 21:42:18 +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 <0JJA005119IG5I00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 13:42:16 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA000CJ9IFHJE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 13:42:16 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l57KgCg3000961; Thu, 07 Jun 2007 16:42:12 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l57KgCfj007655; Thu, 07 Jun 2007 16:42:12 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l57KgCAJ007652; Thu, 07 Jun 2007 16:42:12 -0400 (EDT) Date: Thu, 07 Jun 2007 16:42:12 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <46685090.9070709@sun.com> To: Ashish Joshi Cc: Gary Winiger , PSARC-ext@sun.com, rampart , Michael Bender Message-id: <18024.28068.426137.745161@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> Status: RO Content-Length: 1618 Ashish Joshi writes: > > Does this mean that Sun Ray will need and get a contract? I don't see > > one in the case directory. > > > > > Because Sun Ray is using now Uncommitted interfaces? Yes. Changes without notification are allowed at Minor release boundaries, and there's no way for Sun Ray to know. > I guess. I'll > check with Gary when he's back (on Monday?). OK. > > (In other words, I don't see a difference between codes 4 and 0.) > > > > Mounting/unmounting during allocation/deallocation (done through > device_clean) is done only in TX. Understood. > In TX, if allocate does not mount the device (for non-mountable > devices, and for mountable devices for which user opts to not mount > them), allocate needs to create device nodes in the non-global zone in > which the device is being allocated. Yep. > So, there needs to be a distinction between general success (0) and > mount success (4) because allocate needs to know that it has to create > device nodes in the non-global zone after general success from > device_clean, but not after mount success from device_clean. Because something else creates the nodes or because the nodes are not needed or wanted in that case? Having multiple flavors of success seems like a mistake to me (given the usual design pattern for UNIX interfaces), but I guess it's just a nit and I'll let it drop. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Michael.Bender@sun.com Thu Jun 7 15:33:03 2007 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 l57MX3ko027543 for ; Thu, 7 Jun 2007 15:33:03 -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 l57MVa70017153; Thu, 7 Jun 2007 15:31:36 -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 <0JJA00F05EKMQJ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 15:31:34 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA0059LEKMWB50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 15:31:34 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l57MVYPb025489; Thu, 07 Jun 2007 15:31:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJA00K01EJQZ400@fe-sfbay-10.sun.com> (original mail from Michael.Bender@Sun.COM); Thu, 07 Jun 2007 15:31:34 -0700 (PDT) Received: from [192.9.64.102] ([24.23.213.144]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJA0065HEKL6M60@fe-sfbay-10.sun.com>; Thu, 07 Jun 2007 15:31:33 -0700 (PDT) Date: Thu, 07 Jun 2007 15:31:34 -0700 From: Michael Bender/MBP Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <46685090.9070709@sun.com> Sender: Michael.Bender@sun.com To: Ashish Joshi Cc: James Carlson , Gary Winiger , PSARC-ext@sun.com, rampart Reply-to: Michael.Bender@sun.com Message-id: <46688746.4040105@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 2305 Ashish Joshi wrote: > James Carlson wrote: >> Gary Winiger writes: >> >>> Evolving to Uncommitted is requested in light of a future planned but, >>> not yet scheduled, project to integrate the device allocation >>> functionality >>> under Tamarack: Removable Media Enhancements in Solaris (PSARC/2005/399) >>> for all of the Solaris configurations. >> >> >> Does this mean that Sun Ray will need and get a contract? I don't see >> one in the case directory. >> > > > Because Sun Ray is using now Uncommitted interfaces? I guess. I'll > check with Gary when he's back (on Monday?). > > >>> + On a system configured with Trusted Extensions, the >>> + following additional exit values are returned: >>> + >>> + 3 Mounting of device failed. Caller shall not >>> + place device in error state. >>> + >>> + 4 Mounting of device succeeded. >> >> >> This seems a little over-complicated. I would suggest returning 0 for >> the mount-succeeded case and adding just: >> >> 3 Allocation succeeded, but mounting failed. Media may >> be in unformatted state. Caller should not assume >> device has failed. >> >> (In other words, I don't see a difference between codes 4 and 0.) >> > > Mounting/unmounting during allocation/deallocation (done through > device_clean) is done only in TX. > In TX, if allocate does not mount the device (for non-mountable > devices, and for mountable devices for which user opts to not mount > them), allocate needs to create device nodes in the non-global zone in > which the device is being allocated. > So, there needs to be a distinction between general success (0) and > mount success (4) because allocate needs to know that it has to create > device nodes in the non-global zone after general success from > device_clean, but not after mount success from device_clean. Yes, we were running into the situation where the user plugs in a USB device that doesn't not have a mountable filesystem on it, and without the ability for allocate to be told the difference between "device error" and "device is OK, but just doesn't have anything that the system can mount", these devices were all winding up in the device error state which required admin intervention to clean up. mike From scott.rotondo@sun.com Fri Jun 8 16:16:07 2007 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 l58NG6ph001190 for ; Fri, 8 Jun 2007 16:16:06 -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 l58NEaCG008708; Sat, 9 Jun 2007 07:14:37 +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 <0JJC00107B8CCX00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 16:14:36 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJC009F5B86HKC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 16:14:30 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l58NETsw025742; Fri, 08 Jun 2007 16:14:29 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l58NESO17602; Fri, 08 Jun 2007 16:14:28 -0700 (PDT) Date: Fri, 08 Jun 2007 16:14:28 -0700 From: Scott Rotondo Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18024.28068.426137.745161@gargle.gargle.HOWL> To: James Carlson Cc: Ashish Joshi , Gary Winiger , PSARC-ext@sun.com, rampart , Michael Bender Message-id: <4669E2D4.8040700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 1364 James Carlson wrote: > Ashish Joshi writes: > >> So, there needs to be a distinction between general success (0) and >> mount success (4) because allocate needs to know that it has to create >> device nodes in the non-global zone after general success from >> device_clean, but not after mount success from device_clean. > > Because something else creates the nodes or because the nodes are not > needed or wanted in that case? > > Having multiple flavors of success seems like a mistake to me (given > the usual design pattern for UNIX interfaces), but I guess it's just a > nit and I'll let it drop. I wish you wouldn't; it seems wrong to me too. It seems to me that allocate should create the device nodes regardless of whether a file system was mounted, and therefore a single exit status for success is sufficient. Even if I mounted a file system at allocation time, I should be able to unmount it and access the device node directly without deallocating first. Doesn't that match how it works in the global zone? A more basic question: This case mentions the fact that mounting file systems during allocation is unique to TX, but I believe the difference is simply due to historical accident. Wouldn't it make sense to provide this feature to all Solaris users of device allocation, regardless of whether TX is enabled or not? Scott From Glenn.Faden@Sun.COM Fri Jun 8 17:22:00 2007 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 l590M0Yv001993 for ; Fri, 8 Jun 2007 17:22:00 -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 l590KVB8008861; Fri, 8 Jun 2007 17:20:31 -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 <0JJC00601EA72U00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 17:20:31 -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 <0JJC009MKEA7HNE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 17:20:31 -0700 (PDT) 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 l590KV8b016099; Fri, 08 Jun 2007 17:20:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJC00301E651300@fe-sfbay-10.sun.com> (original mail from Glenn.Faden@Sun.COM); Fri, 08 Jun 2007 17:20:31 -0700 (PDT) Received: from [192.168.0.11] ([71.202.95.125]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJC00HHXEA3HH40@fe-sfbay-10.sun.com>; Fri, 08 Jun 2007 17:20:27 -0700 (PDT) Date: Fri, 08 Jun 2007 17:18:09 -0700 From: Glenn Faden Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <4669E2D4.8040700@sun.com> Sender: Glenn.Faden@Sun.COM To: Scott Rotondo Cc: James Carlson , Ashish Joshi , Gary Winiger , PSARC-ext@Sun.COM, rampart , Michael Bender Message-id: <4669F1C1.8020000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 1886 Scott Rotondo wrote: > > It seems to me that allocate should create the device nodes regardless > of whether a file system was mounted, and therefore a single exit > status for success is sufficient. Even if I mounted a file system at > allocation time, I should be able to unmount it and access the device > node directly without deallocating first. Doesn't that match how it > works in the global zone? First of all, the design of device allocation in TX is not the subject of this fast track. TX has always mounted the allocated device without creating a device node in the non-global zone. This case is only about providing better feedback to what is going on so that Sun Ray software can work more reliably. Whenever possible we should avoid creating devices in non-global zones. Unfortunately, it is possible to panic the kernel from a non-global zone if a root process has access to the raw device while it is simultaneously mounted as a file system. If you scribble over the mounted filesystem you can cause a panic. It is critical to our security story to assert that a root process in a non-global zone cannot crash the kernel or other zones. > > A more basic question: This case mentions the fact that mounting file > systems during allocation is unique to TX, but I believe the > difference is simply due to historical accident. Wouldn't it make > sense to provide this feature to all Solaris users of device > allocation, regardless of whether TX is enabled or not? Again, that is not the subject of this case. This is about supporting device allocation in zones by Sun Ray software. If device allocation in standard Solaris is actually important to customers, we could extend the functionality in standard Solaris. However, I think that would done differently; probably based on HAL and the GNOME Removeable Drives and Media application. --Glenn From gww@eng.sun.com Sat Jun 9 07:42:00 2007 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 l59Efxed021542 for ; Sat, 9 Jun 2007 07:41:59 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l59EeUXH014207 for <@newsunmail1brm.central.sun.com:PSARC-ext@sun.com>; Sat, 9 Jun 2007 15:40:31 +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 <0JJD00201I3ISK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Jun 2007 08:40:30 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJD00L20I3HMYA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Jun 2007 08:40:29 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l59EeSgS008161; Sat, 09 Jun 2007 07:40:28 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l59EgvPp007644; Sat, 09 Jun 2007 07:42:57 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l59Egvee007643; Sat, 09 Jun 2007 07:42:57 -0700 (PDT) Date: Sat, 09 Jun 2007 07:42:57 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com Cc: ashish.joshi@sun.com Message-id: <200706091442.l59Egvee007643@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 8810 > Solution 3: > =========== > Add a new key word, "class" in device_allocate(4) (key words were > introduced in PSARC/2005/691, but are missing from the current man page > -- see case directory) to the existing key words to distinguish a class > of devices. Add a new key word, "xdpy" in device_allocate(4) to the > existing key words to store an X Display name. Both new key words > are generic and are not restricted to SunRay operation. SunRay is the > first identified consumer. > add_allocatable(1M) and remove_allocatable(1M) are used to update > device_allocate(4). From the pre-review, I'm still having trouble with the efficacy of class and xdpy. I believe I see where class can be used in deallocate and list_devices to deallocate a "class" of devices as a single unit and to display for human consumption a class of devices to identify their status. However, "xdpy" seem to be "write only". add_allocatable will update the field, however I don't see how it is possible to use the field outside of allocate, deallocate, list_devices. There seems to be no public programming interface to retrieve or filter on its value. If it is returned by list_devices, the output of list_devices is Not-An-Interface. None of the library routines for device_allocate(4) are scoped public. So why are both "class" and "xdpy" required? How should xdpy be used? This seems different from "zone," which I can intuit being used for internal bookkeeping in allocate/deallocate to identify the labeled zone where the allocated device nodes reside. Gary.. > > device_allocate(4): > ~~~~~~~~~~~~~~~~~~~~~~ > > DESCRIPTION > The device_allocate file contains mandatory access control > information about each physical device. Each device is > represented by a one line entry of the form: > > ~ device-name;device-type;reserved1;reserved2;auths;device-exec > > device-type This is an arbitrary ASCII string naming the > generic device type. This field identifies > and groups together devices of like type. > This field contains no embedded white space > ~ or non-printable characters. The following > ~ types of devices are currently managed by the > ~ system: audio, sr (represents CDROM drives), > ~ fd (represents floppy drives), st (represents > ~ tape drives), rmdisk (removable media devices) > > ~ reserved1 On systems configured with Trusted Extensions, > ~ this field stores a colon-separated (:) list > ~ of key-value pairs that describe device > ~ allocation attributes used in Trusted > ~ Extensions. Zero or more keys may be > ~ specified. The following keys are currently > ~ interpreted by Trusted Extensions systems: > ~ minlabel Specifies the minimum label at > ~ which device can be allocated. > ~ Default value is admin_low. > ~ maxlabel Specifies the maximum label at > ~ which device can be allocated. > ~ Default value is admin_high. > ~ zone Specifies the name of the zone > ~ in which device is currently > ~ allocated. > + class Specifies a logical grouping > + of devices. For e.g., all Sun > + Ray devices of all device types. > + There is no default class. > + xdpy Specifies the X Display name. > + This is used to identify devices > + associated with that X session. > + There is no default xdpy value. > > add_allocatable(1M): > ~~~~~~~~~~~~~~~~~~~~~~ > > OPTIONS > > -o key=value Accepts a string of colon-separated > key=value pairs for a device that is speci- > fied with -n or with devices of the type > that is specified with -t. The following > keys are currently interpreted by the sys- > tem: > > minlabel The minimum label at which the dev- > ice can be used. > > maxlabel The maximum label at which the dev- > ice can be used. > > + class Specifies a logical grouping of > + devices. For e.g., all SunRay > + devices of all device types. There > + no default class specified. > + > + xdpy Specifies the X Display name. > + This is used to identify devices > + associated with that X session. > + There is no default xdpy value. > > remove_allocatable(1M): > ~~~~~~~~~~~~~~~~~~~~~~ > > SYNOPSIS > | /usr/sbin/remove_allocatable [-f] [-n name | -c dev-class] > > /usr/sbin/remove_allocatable [-f] [-d] -t dev-type > > OPTIONS > > + -c dev-class Removes devices that belong to dev-class. > > deallocate(1): > ~~~~~~~~~~~~~~~~~~~~~~ > > SYNOPSIS > | deallocate [-s] [-w] [-F] [-z zonename] > + [-c dev-class | -g dev-type | device] > > - deallocate [-s] [-w] [-F] [-z zonename] -g dev-type > > deallocate [-s] [-w] [-F] [-z zonename] -I > > OPTIONS > The following options are supported: > > + -c dev-class Deallocates all devices of the specified > + device class. > > list_devices(1): > ~~~~~~~~~~~~~~~~~~~~~~ > > SYNOPSIS > list_devices [-s] [-U uid] [-z zonename] [-a] > | [-l | -n | -u] [-c dev-class | device] > > DESCRIPTION > The list_devices utility lists the allocatable devices in > the system according to specified qualifications. > > The device and all device special files associated with the > device are listed. The device argument is optional and, if > | it is not present, all relevant devices are listed, unless > + dev-class is present, in which case devices belonging to the > + specified dev-class are listed. There is no default > + dev-class. > > OPTIONS > The following options are supported: > > | -l [-c dev-class | device] > Lists the pathname(s) of the device special > files associated with the device that are > | allocatable to the current process. > + If dev-class is given, lists only the files > + associated with all devices of the specified > + device class. > | If device is given, lists only the files > | associated with the specified device. > > | -n [-c dev-class | device] > Lists the pathname(s) of device special files > associated with the device that are allocat- > able to the current process but are not > | currently allocated. > + If dev-class is given, lists only the files > + associated with all devices of the specified > + device class. > | If device is given, lists only the files > | associated with the specified device. > > | -u [-c dev-class | device] > Lists the pathname(s) of device special > files, associated with the device that are > allocated to the owner of the current pro- > | cess. > + If dev-class is given, lists only the files > + associated with all devices of the specified > + device class. > | If device is given, lists only the files > | associated with the specified device. > > -U uid Uses the user ID uid instead of the real user > ID of the current process when performing the > list_devices operation. Only a user with the > solaris.device.revoke authorization can use > this option. > > -s Silent. Suppresses any diagnostic output. > From gww@eng.sun.com Sat Jun 9 08:21:44 2007 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 l59FLhhZ023933 for ; Sat, 9 Jun 2007 08:21:44 -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 l59FKEND015143 for <@sunmail3mpk.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Jun 2007 23:20:15 +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 <0JJD00901JXQDX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Jun 2007 08:20:14 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJD006M4JXQGJA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Jun 2007 08:20:14 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l59FKDmL010618; Sat, 09 Jun 2007 08:20:13 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l59FMgRR007663; Sat, 09 Jun 2007 08:22:42 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l59FMgdu007662; Sat, 09 Jun 2007 08:22:42 -0700 (PDT) Date: Sat, 09 Jun 2007 08:22:42 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates To: gww@sac.sfbay.sun.com, james.d.carlson@sun.com Cc: PSARC-ext@sun.com, ashish.joshi@sun.com Message-id: <200706091522.l59FMgdu007662@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1000 > Gary Winiger writes: > > Evolving to Uncommitted is requested in light of a future planned but, > > not yet scheduled, project to integrate the device allocation functionality > > under Tamarack: Removable Media Enhancements in Solaris (PSARC/2005/399) > > for all of the Solaris configurations. > > Does this mean that Sun Ray will need and get a contract? I don't see > one in the case directory. This one is mine, not the project team's. In clarifying the output, Unstable -> Not-An-Interface, I suggested Evolving -> Uncommitted. It seemed to me that even with Uncommitted, full notification of incompatible change/EOL/EOF processing is needed and the boundary is Minor. So, just like non-Sun consumers, unbundled Sun consumers would be adequately notified. Of course, if members believe it's necessary/desirable, a contract can be drawn. As I'm presently away -- and Ashish is likely optimistic about my return date -- let's not hold things up only for a contract. Gary.. From Glenn.Faden@sun.com Sat Jun 9 11:46:42 2007 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 l59Ikg5w026604 for ; Sat, 9 Jun 2007 11:46:42 -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 l59Iinl5063694; Sat, 9 Jun 2007 12:44:49 -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 <0JJD00L07TFEKS00@brm-avmta-1.central.sun.com>; Sat, 09 Jun 2007 12:45:14 -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 <0JJD00J5DTFDUW40@brm-avmta-1.central.sun.com>; Sat, 09 Jun 2007 12:45:13 -0600 (MDT) 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 l59IjDgQ011202; Sat, 09 Jun 2007 11:45:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJD00D01T9OS700@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Sat, 09 Jun 2007 11:45:13 -0700 (PDT) Received: from [129.150.12.206] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJD009KWTFC5U20@fe-sfbay-09.sun.com>; Sat, 09 Jun 2007 11:45:13 -0700 (PDT) Date: Sat, 09 Jun 2007 11:42:55 -0700 From: Glenn Faden Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <200706091442.l59Egvee007643@marduk.eng.sun.com> Sender: Glenn.Faden@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, gww@sac.sfbay.sun.com, ashish.joshi@sun.com Message-id: <466AF4AF.7020403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706091442.l59Egvee007643@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 2829 Gary Winiger wrote: >> Solution 3: >> =========== >> Add a new key word, "class" in device_allocate(4) (key words were >> introduced in PSARC/2005/691, but are missing from the current man page >> -- see case directory) to the existing key words to distinguish a class >> of devices. Add a new key word, "xdpy" in device_allocate(4) to the >> existing key words to store an X Display name. Both new key words >> are generic and are not restricted to SunRay operation. SunRay is the >> first identified consumer. >> add_allocatable(1M) and remove_allocatable(1M) are used to update >> device_allocate(4). >> > > From the pre-review, I'm still having trouble with the efficacy > of class and xdpy. I believe I see where class can be used > in deallocate and list_devices to deallocate a "class" of devices > as a single unit and to display for human consumption a class of > devices to identify their status. However, "xdpy" seem to be > "write only". add_allocatable will update the field, however > I don't see how it is possible to use the field outside of > allocate, deallocate, list_devices. There seems to be no public > programming interface to retrieve or filter on its value. > If it is returned by list_devices, the output of list_devices > is Not-An-Interface. None of the library routines for > device_allocate(4) are scoped public. > > So why are both "class" and "xdpy" required? How should xdpy > be used? > The output of list devices is consumed by the CDE and JDS device allocation tools. This has been the design for over 10 years. The output is in the form of key=value lists, and is parseable. The xdpy value is the display number corresponding to the specific X server associated with the logged in user. Each user, whether on the console or a Sun Ray appliance, has his own X server with a unique port number, starting at 6000. By convention, 0 corresponds to 6000. From a user's perspective the only devices of interest are those associated with his session (not all Sun Ray sessions). The user cannot run any of the allocate, deallocate or list_devices commands. Instead, the user interacts with the CDE or JDS GUI which, in turn, runs these commands. Both GUIs filter the output of list_devices by matching the xdpy value with its own $DISPLAY value. So the user cannot see or allocate devices associated with other sessions. The CLIs don't interpret the xdpy value. That's because the CLIs have no knowledge of X windows. > This seems different from "zone," which I can intuit being used > for internal bookkeeping in allocate/deallocate to identify the > labeled zone where the allocated device nodes reside. > It is not related to zone. Remember that in a given zone there could be a hundred Sun Ray users, each with their own xdpy value. --Glenn From gww@eng.sun.com Sun Jun 10 08:22:42 2007 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 l5AFMg1E010146 for ; Sun, 10 Jun 2007 08:22:42 -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 l5AFKn6u048502 for <@sunmail3mpk.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 10 Jun 2007 09:20:49 -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 <0JJF00201ENDGH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 10 Jun 2007 08:21:13 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJF00MO7ENCIM50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 10 Jun 2007 08:21:13 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5AFLBQq010597; Sun, 10 Jun 2007 08:21:11 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5AFNgBx007916; Sun, 10 Jun 2007 08:23:42 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5AFNges007915; Sun, 10 Jun 2007 08:23:42 -0700 (PDT) Date: Sun, 10 Jun 2007 08:23:42 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates To: Glenn.Faden@sun.com, gww@eng.sun.com Cc: PSARC-ext@sun.com, ashish.joshi@sun.com, craig.payne@sun.com, gww@sac.sfbay.sun.com Message-id: <200706101523.l5AFNges007915@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2364 > > So why are both "class" and "xdpy" required? How should xdpy > > be used? > > > The output of list devices is consumed by the CDE and JDS device > allocation tools. This has been the design for over 10 years. The output > is in the form of key=value lists, and is parseable. Exactly my point. In the original case 2005/691 and in this case and in my conversations in pre-review, the output from list_devices is NOT a programming interface. It was previously ARCed as Unstable. That was clarified here to be Not-An-Interface. I find no contracts in 2005/691 for any consumers, nor options on the man page for a format of output that is an interface. Nor documentation of what that output might be. Indeed when I talked with the project team (long before the last minute addition of xdpy), I explicitly asked how the output was consumed. IIRC, the answer was it was displayed verbatim to the user who then choose what to do. And I suggested a possible stable form of output in XML, with a new option "-x." The project cannot have it both ways. Not-An-Interface != Committed > The xdpy value is the display number corresponding to the specific X > server associated with the logged in user. Each user, whether on the > console or a Sun Ray appliance, has his own X server with a unique port I got that. That's clear. What wasn't clear is how xdpy was to be used. There is no stable interface to consume it, thus it had to be used only internally to allocate/deallocate/list_devices. And that didn't make sense. > > This seems different from "zone," which I can intuit being used > > for internal bookkeeping in allocate/deallocate to identify the > > labeled zone where the allocated device nodes reside. > > > It is not related to zone. Remember that in a given zone there could be > a hundred Sun Ray users, each with their own xdpy value. That's what I was trying to say "zone" was used internally for bookkeeping and allocate/deallocate/list_devices filtering. There is no proposed equivalent to "-c" (class) or "-z" (zonename) to filter on "xdpy". It seems like there are missing interfaces one way or another. More filter options, or stable parsable output options for list_devices seem the alternatives. I'm not trying to design on the fly here. The design's up to the project team. Gary.. From Glenn.Faden@sun.com Sun Jun 10 14:06:15 2007 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 l5AL6DtB013939 for ; Sun, 10 Jun 2007 14:06:14 -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 l5AL4emc020928; Mon, 11 Jun 2007 05:04:42 +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 <0JJF00M01UJSPL00@nwk-avmta-2.sfbay.sun.com>; Sun, 10 Jun 2007 14:04:41 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJF00APLUJSARD0@nwk-avmta-2.sfbay.sun.com>; Sun, 10 Jun 2007 14:04:40 -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 l5AL4e4x027227; Sun, 10 Jun 2007 14:04:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJF00J01UH35V00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Sun, 10 Jun 2007 14:04:40 -0700 (PDT) Received: from [129.150.12.206] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJF00I95UJHKHB0@fe-sfbay-09.sun.com>; Sun, 10 Jun 2007 14:04:40 -0700 (PDT) Date: Sun, 10 Jun 2007 14:02:18 -0700 From: Glenn Faden Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <200706101523.l5AFNges007915@marduk.eng.sun.com> Sender: Glenn.Faden@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, ashish.joshi@sun.com, Craig.Payne@sun.com, gww@sac.sfbay.sun.com Message-id: <466C66DA.4030203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706101523.l5AFNges007915@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 4145 Gary Winiger wrote: >>> So why are both "class" and "xdpy" required? How should xdpy >>> be used? >>> >>> >> The output of list devices is consumed by the CDE and JDS device >> allocation tools. This has been the design for over 10 years. The output >> is in the form of key=value lists, and is parseable. >> > > Exactly my point. In the original case 2005/691 and in this > case and in my conversations in pre-review, the output from > list_devices is NOT a programming interface. It was previously > ARCed as Unstable. It is stable, but extensible. I think that may have been the source of confusion. > That was clarified here to be Not-An-Interface. > I find no contracts in 2005/691 for any consumers, nor options > on the man page for a format of output that is an interface. > Nor documentation of what that output might be. Indeed when I > talked with the project team (long before the last minute addition > of xdpy), I explicitly asked how the output was consumed. IIRC, > the answer was it was displayed verbatim to the user who then > choose what to do. Sorry, that was a mistake. The user in TX cannot directly run or observe any of these commands. The only user interface is the GUI. The GUI is the consumer. > And I suggested a possible stable form of > output in XML, with a new option "-x." > > The project cannot have it both ways. Not-An-Interface != Committed > The output of list_devices is an interface which is parsable. It contains a set of key-value pairs which is extensible. For example, here is the output of the entry for the console audio device, which has been allocated by me in the public zone. device=audio0;type=audio;auths=solaris.device.allocate;clean=/etc/security/lib/audio_clean_wrapper;minlabel=admin_low:maxlabel=admin_high;zone=public:owner=11115;files=/dev/audio /dev/audioctl:xdpy=0 The output of list_devices was changed to be parsable in TSOL 7. This case is partly about specifying what the interfaces are, but the actual architecture (especially the CDE code) has not changed in 10 years. Prior to that the GUIs contained a copy of most of the source code of the allocate command (the file allocate3.c). > >> The xdpy value is the display number corresponding to the specific X >> server associated with the logged in user. Each user, whether on the >> console or a Sun Ray appliance, has his own X server with a unique port >> > > I got that. That's clear. What wasn't clear is how xdpy was > to be used. There is no stable interface to consume it, thus > it had to be used only internally to allocate/deallocate/list_devices. > And that didn't make sense. > The implementation of the device_allocate file is extensible, like the RBAC databases. The list_devices command will simply display all the keywords in the file. The GUI's parse the output to generate the UI components. > >>> This seems different from "zone," which I can intuit being used >>> for internal bookkeeping in allocate/deallocate to identify the >>> labeled zone where the allocated device nodes reside. >>> >>> >> It is not related to zone. Remember that in a given zone there could be >> a hundred Sun Ray users, each with their own xdpy value. >> > > That's what I was trying to say "zone" was used internally for > bookkeeping and allocate/deallocate/list_devices filtering. > There is no proposed equivalent to "-c" (class) or "-z" (zonename) > to filter on "xdpy". > zone is one of the keywords output by list_devices. It is interpreted by the GUI, which looks up the label of the device and displays it. > It seems like there are missing interfaces one way or another. > More filter options, or stable parsable output options for > list_devices seem the alternatives. > Yes, the output of list_devices is stable in that it consists of key=value pairs separated by colons. The keys are extensible. > I'm not trying to design on the fly here. The design's up to > the project team. > The design was completed long ago, but the interfaces have not been properly conveyed to PSARC. --Glenn From Psm.Swamiji@sun.com Sun Jun 10 23:31:29 2007 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 l5B6VSTs020021 for ; Sun, 10 Jun 2007 23:31:29 -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 l5B6TnVb000367; Mon, 11 Jun 2007 14:29:56 +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 <0JJG00I01KPUI200@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 00:29:54 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJG00C6WKPS9B30@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 00:29:53 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5B6TqtS000120; Mon, 11 Jun 2007 06:29:52 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJG00001KKV3300@mail-apac.sun.com> (original mail from Psm.Swamiji@Sun.COM); Mon, 11 Jun 2007 14:29:51 +0800 (SGT) Received: from [10.12.145.103] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJG00750KPQ6YWV@mail-apac.sun.com>; Mon, 11 Jun 2007 14:29:51 +0800 (SGT) Date: Mon, 11 Jun 2007 11:57:34 +0530 From: "P.S.M. Swamiji" Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <466C66DA.4030203@sun.com> Sender: Psm.Swamiji@sun.com To: Glenn Faden Cc: Gary Winiger , PSARC-ext@sun.com, Craig.Payne@sun.com, ashish.joshi@sun.com, gww@sac.sfbay.sun.com Message-id: <466CEB56.5020302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, fr, zh-cn, en X-PMX-Version: 5.2.0.264296 References: <200706101523.l5AFNges007915@marduk.eng.sun.com> <466C66DA.4030203@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060629 Status: RO Content-Length: 1580 Glenn Faden wrote: >>>> This seems different from "zone," which I can intuit being used >>>> for internal bookkeeping in allocate/deallocate to identify the >>>> labeled zone where the allocated device nodes reside. >>>> >>> >>> It is not related to zone. Remember that in a given zone there could >>> be a hundred Sun Ray users, each with their own xdpy value. >>> >> >> >> That's what I was trying to say "zone" was used internally for >> bookkeeping and allocate/deallocate/list_devices filtering. >> There is no proposed equivalent to "-c" (class) or "-z" (zonename) >> to filter on "xdpy". >> > > > zone is one of the keywords output by list_devices. I don't see list_devices returning of zone is one of the keywords output on TX. Did I miss anything here?. Thanks P.S.M.Swamiji > It is interpreted by the GUI, which looks up the label of the device > and displays it. > >> It seems like there are missing interfaces one way or another. >> More filter options, or stable parsable output options for >> list_devices seem the alternatives. > > Yes, the output of list_devices is stable in that it consists of > key=value pairs separated by colons. The keys are extensible. > >> I'm not trying to design on the fly here. The design's up to >> the project team. >> > > The design was completed long ago, but the interfaces have not been > properly conveyed to PSARC. > > --Glenn > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From carlsonj@phorcys.east.sun.com Mon Jun 11 05:11:13 2007 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 l5BCBCDp025951 for ; Mon, 11 Jun 2007 05:11:13 -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 l5BC9VR0026485; Mon, 11 Jun 2007 20:09:39 +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 <0JJH00J050G27Z00@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 06:09:38 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00IU80G1KO00@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 06:09:37 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5BC9ZBV001554; Mon, 11 Jun 2007 08:09:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5BC9Zu2001551; Mon, 11 Jun 2007 08:09:35 -0400 (EDT) Date: Mon, 11 Jun 2007 08:09:35 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <200706091522.l59FMgdu007662@marduk.eng.sun.com> To: Gary Winiger Cc: gww@sac.sfbay.sun.com, PSARC-ext@sun.com, ashish.joshi@sun.com Message-id: <18029.15231.513192.512131@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706091522.l59FMgdu007662@marduk.eng.sun.com> Status: RO Content-Length: 1747 Gary Winiger writes: > This one is mine, not the project team's. In clarifying the > output, Unstable -> Not-An-Interface, I suggested > Evolving -> Uncommitted. It seemed to me that even with Note that in the updated taxonomy, both ON and PSARC have treated "Evolving" as essentially "Committed." Some others historically considered "Evolving" to be what we now call "Uncommitted," but I think doing something different requires some explanation. See: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp#EXPSARC > Uncommitted, full notification of incompatible change/EOL/EOF > processing is needed and the boundary is Minor. So, just like No, Uncommitted does not require "full notification." It requires "impact assessment" for incompatible change, and none at all for other change. Note also that it's intended for experimental, transitional, or otherwise undependable interfaces. Is that really what we're describing here? The "impact assessment" in this case is exactly what a contract would document. > non-Sun consumers, unbundled Sun consumers would be adequately > notified. > > Of course, if members believe it's necessary/desirable, a contract > can be drawn. As I'm presently away -- and Ashish is likely > optimistic about my return date -- let's not hold things up > only for a contract. Given the lack of visibility into Sun Ray that we have on the ARC, I think I need to insist on a contract to nail this down. We really have no way of knowing what the impact might be. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Mon Jun 11 05:20:42 2007 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 l5BCKfhM026019 for ; Mon, 11 Jun 2007 05:20:42 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5BCHTtE026434; Mon, 11 Jun 2007 13:17:41 +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 <0JJH00H090TFQO00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 05:17:39 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH007B50TECJF0@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 05:17:38 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5BCHbES001577; Mon, 11 Jun 2007 08:17:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5BCHbK3001574; Mon, 11 Jun 2007 08:17:37 -0400 (EDT) Date: Mon, 11 Jun 2007 08:17:37 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <4669F1C1.8020000@sun.com> To: Glenn Faden Cc: Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Michael Bender , Ashish Joshi Message-id: <18029.15713.142967.593236@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> Status: RO Content-Length: 1819 Glenn Faden writes: > Whenever possible we should avoid creating devices in non-global zones. > Unfortunately, it is possible to panic the kernel from a non-global zone > if a root process has access to the raw device while it is > simultaneously mounted as a file system. If you scribble over the > mounted filesystem you can cause a panic. It is critical to our security > story to assert that a root process in a non-global zone cannot crash > the kernel or other zones. If the inserted device has no recognizable file system on it, or if the one we recognize cannot be mounted, then we create a device node in the zone. If it can be mounted, then only the mount point is inserted in the zone for security reasons. But how can this be a complete answer? If the user inserts either a blank medium or a device with an intentionally damaged file system, he gets a device node. He can then mount it, scribble on it, and torch the system. Did I miss something? > Again, that is not the subject of this case. This is about supporting > device allocation in zones by Sun Ray software. If device allocation in > standard Solaris is actually important to customers, we could extend the > functionality in standard Solaris. However, I think that would done > differently; probably based on HAL and the GNOME Removeable Drives and > Media application. It'd be nice if this corner of the world weren't baroque. The only thing that keeps my hand away from the derail lever is the lack of Sun Ray engagement in the ARC; I have little expectation that a full review would be productive. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Glenn.Faden@sun.com Mon Jun 11 11:32:49 2007 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 l5BIWm28004961 for ; Mon, 11 Jun 2007 11:32:49 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5BIVEX5010975; Mon, 11 Jun 2007 19:31:15 +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 <0JJH00109I428C00@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 12:31:14 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00K38I3V1040@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 12:31:08 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5BIV76h000233; Mon, 11 Jun 2007 11:31:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJH00E01H3TIP00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Mon, 11 Jun 2007 11:31:07 -0700 (PDT) Received: from lockbox.Eng.Sun.COM ([129.146.108.200]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJH00KGWI3MKBH0@fe-sfbay-09.sun.com>; Mon, 11 Jun 2007 11:30:59 -0700 (PDT) Date: Mon, 11 Jun 2007 11:24:50 -0700 From: Glenn Faden Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18029.15713.142967.593236@gargle.gargle.HOWL> Sender: Glenn.Faden@sun.com To: James Carlson Cc: Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Michael Bender , Ashish Joshi Message-id: <466D9372.6090104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070312) Status: RO Content-Length: 2616 James Carlson wrote: > Glenn Faden writes: > >> Whenever possible we should avoid creating devices in non-global zones. >> Unfortunately, it is possible to panic the kernel from a non-global zone >> if a root process has access to the raw device while it is >> simultaneously mounted as a file system. If you scribble over the >> mounted filesystem you can cause a panic. It is critical to our security >> story to assert that a root process in a non-global zone cannot crash >> the kernel or other zones. >> > > If the inserted device has no recognizable file system on it, or if > the one we recognize cannot be mounted, then we create a device node > in the zone. If it can be mounted, then only the mount point is > inserted in the zone for security reasons. > > But how can this be a complete answer? If the user inserts either a > blank medium or a device with an intentionally damaged file system, he > gets a device node. He can then mount it, scribble on it, and torch > the system. > > Did I miss something? > The policy for how to handle such media is specified in the device_clean script. Customers are free to write their own customized scripts since the interface is stable. In particular, the SRSS 4.0 release includes Sun Ray-specific device_clean scripts. In the case of hot-plugged USB devices they never create a device node in any labeled zone. If the device isn't recognized as mountable, the allocation is denied. We have other requests coming from our customers to have a per-user fine-grained policy of whether they can do read-only or read-write mounts. The current design supports this because the authorizations for each device are configurable and extensible. We can create separate authorizations for read-only and read-write mounts, and assign one or the other to individual users. The device_clean script can check the authorizations (using auths(1)) and set the appropriate mount options. --Glenn >> Again, that is not the subject of this case. This is about supporting >> device allocation in zones by Sun Ray software. If device allocation in >> standard Solaris is actually important to customers, we could extend the >> functionality in standard Solaris. However, I think that would done >> differently; probably based on HAL and the GNOME Removeable Drives and >> Media application. >> > > It'd be nice if this corner of the world weren't baroque. The only > thing that keeps my hand away from the derail lever is the lack of Sun > Ray engagement in the ARC; I have little expectation that a full > review would be productive. > > From carlsonj@phorcys.east.sun.com Mon Jun 11 11:46:33 2007 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 l5BIkX1Z005347 for ; Mon, 11 Jun 2007 11:46:33 -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 l5BIj1gt028507; Mon, 11 Jun 2007 11:45:02 -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 <0JJH00503IR11V00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 11:45:01 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00K0BIR04C60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 11:45:00 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5BIixoF003048; Mon, 11 Jun 2007 14:44:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5BIixFQ003045; Mon, 11 Jun 2007 14:44:59 -0400 (EDT) Date: Mon, 11 Jun 2007 14:44:59 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <466D9372.6090104@sun.com> To: Glenn Faden Cc: Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Michael Bender , Ashish Joshi Message-id: <18029.38955.166290.646568@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466D9372.6090104@sun.com> Status: RO Content-Length: 1204 Glenn Faden writes: > The policy for how to handle such media is specified in the device_clean > script. Customers are free to write their own customized scripts since > the interface is stable. In particular, the SRSS 4.0 release includes > Sun Ray-specific device_clean scripts. In the case of hot-plugged USB > devices they never create a device node in any labeled zone. If the > device isn't recognized as mountable, the allocation is denied. I see. In that case, it makes a lot more sense to me that we'd simply have a way of saying that the policy is "no device nodes in the zone," regardless of the outcome of the mount attempt. Having a fallback position of mount-point-only first and then raw-device if that fails seems like a mistake. It doesn't seem to represent any useful policy. Yes, I understand that this is ancient policy and not really part of this case. The part that's in this case, though, is the strange use of an "alternate success" exit value. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@eng.sun.com Mon Jun 11 14:11:01 2007 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 l5BLB0uW009512 for ; Mon, 11 Jun 2007 14:11:01 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5BL9TD8025757; Mon, 11 Jun 2007 22:09:29 +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 <0JJH00B0JPFQ5000@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 15:09:26 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00KPDPFP1AD0@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 15:09:25 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5BL9O9F004307; Mon, 11 Jun 2007 14:09:24 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5BLBugB008980; Mon, 11 Jun 2007 14:11:56 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5BLBudr008979; Mon, 11 Jun 2007 14:11:56 -0700 (PDT) Date: Mon, 11 Jun 2007 14:11:56 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates To: Glenn.Faden@sun.com, james.d.carlson@sun.com Cc: PSARC-ext@sun.com, ashish.joshi@sun.com, craig.payne@sun.com, gww@sac.sfbay.sun.com, rampart-dev-team@sun.com, scott.rotondo@sun.com Message-id: <200706112111.l5BLBudr008979@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 626 > It'd be nice if this corner of the world weren't baroque. The only > thing that keeps my hand away from the derail lever is the lack of Sun > Ray engagement in the ARC; I have little expectation that a full > review would be productive. I'm moving this case to waiting need spec. Try as I have, the project team has still failed to provide a full spec. I believe the same to be true of the approved PSARC/2005/691. When the project team provides a full spec, including missing information from PSARC/2005/691, I'll restart the case. I believe the crux of the issues are in the spec, not the architecture. Gary.. From Bart.Blanquart@sun.com Mon Jun 11 14:12:54 2007 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 l5BLCsKg009775 for ; Mon, 11 Jun 2007 14:12:54 -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 l5BLAsd0021361; Mon, 11 Jun 2007 15:10:58 -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 <0JJH00H07PIYP000@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 14:11:22 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00EEIPIVHT40@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 14:11:21 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5BLBJ8A010760; Mon, 11 Jun 2007 21:11:19 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJH00201PH0W700@d1-emea-09.sun.com> (original mail from Bart.Blanquart@Sun.COM); Mon, 11 Jun 2007 22:11:19 +0100 (BST) Received: from [192.168.56.101] ([81.244.212.42]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJH005TZPIUM0M2@d1-emea-09.sun.com>; Mon, 11 Jun 2007 22:11:19 +0100 (BST) Date: Mon, 11 Jun 2007 23:11:17 +0200 From: Bart Blanquart Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <466D9372.6090104@sun.com> Sender: Bart.Blanquart@sun.com To: Glenn Faden Cc: James Carlson , Scott Rotondo , Gary Winiger , rampart , PSARC-EXT@sun.com, Michael Bender , Ashish Joshi Message-id: <8DBBA7FC-FF74-491A-B551-295C19A7B496@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466D9372.6090104@sun.com> Status: RO Content-Length: 1429 > We have other requests coming from our customers to have a per-user > fine-grained policy of whether they can do read-only or read-write > mounts. The current design supports this because the authorizations > for each device are configurable and extensible. We can create > separate authorizations for read-only and read-write mounts, and > assign one or the other to individual users. The device_clean > script can check the authorizations (using auths(1)) and set the > appropriate mount options. Is there a policy documented on what authorization names are usable (i.e. if customers add finer-grained authorizations following the naming examples they may end up with things like solaris.device.cdrom.ro/solaris.device.cdrom.rw/...) so that there won't be conflicts with (similar) authorizations we may add later? (auth_attr(4) implies that another top level name-space should be used instead of 'solaris.', but that seems somewhat unfortunate, as it prevents solaris.* or solaris.device.* from having the expected effect). Regarding the use of auths(1) in scripts: it currently seems to be unsuited for that (even though the man-page recommends this use), as its output is not guaranteed to contain the complete authorization name (e.g. auths output as root is "solaris.*", so grepping for "solaris.device.something" won't give the expected result); CR 6251549 documents this. Bart From Michael.Bender@sun.com Mon Jun 11 14:46:27 2007 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 l5BLkR0X010480 for ; Mon, 11 Jun 2007 14:46:27 -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 l5BLitqD016916; Mon, 11 Jun 2007 14:44:56 -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 <0JJH00D07R2VKF00@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 15:44:55 -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 <0JJH00KXAR2V11E0@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 15:44:55 -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 l5BLisfD010197; Mon, 11 Jun 2007 14:44:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJH00H01R1REZ00@fe-sfbay-10.sun.com> (original mail from Michael.Bender@Sun.COM); Mon, 11 Jun 2007 14:44:54 -0700 (PDT) Received: from sunray3.SFBay.Sun.COM ([10.6.102.113]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJH00GLXR2RD400@fe-sfbay-10.sun.com>; Mon, 11 Jun 2007 14:44:52 -0700 (PDT) Date: Mon, 11 Jun 2007 14:44:51 -0700 From: Michael Bender Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18029.38955.166290.646568@gargle.gargle.HOWL> Sender: Michael.Bender@sun.com To: James Carlson Cc: Glenn Faden , Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Ashish Joshi Reply-to: Michael.Bender@sun.com Message-id: <466DC253.5040300@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466D9372.6090104@sun.com> <18029.38955.166290.646568@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5pre (X11/20070601) Status: RO Content-Length: 1904 James Carlson wrote: > Glenn Faden writes: >> The policy for how to handle such media is specified in the device_clean >> script. Customers are free to write their own customized scripts since >> the interface is stable. In particular, the SRSS 4.0 release includes >> Sun Ray-specific device_clean scripts. In the case of hot-plugged USB >> devices they never create a device node in any labeled zone. If the >> device isn't recognized as mountable, the allocation is denied. > > I see. > > In that case, it makes a lot more sense to me that we'd simply have a > way of saying that the policy is "no device nodes in the zone," > regardless of the outcome of the mount attempt. Having a fallback > position of mount-point-only first and then raw-device if that fails > seems like a mistake. It doesn't seem to represent any useful policy. > > Yes, I understand that this is ancient policy and not really part of > this case. The part that's in this case, though, is the strange use > of an "alternate success" exit value. That is necessary in case someone wants to implement a policy in their device_clean script that gives the user the option of mounting any mountable filesystems on the device or making device nodes available in a local zone. The issue of being able to panic the system due to garbage on the device causing the kernel fs code to puke isn't really related to device allocation and TX specifically - someone could take a USB memory stick to another system (say, a PC or a Mac or a non-TX system, etc...), write garbage on it, and then plug it into a TX system, where our wonderfully (non)-robust filesystem code will toss it's cookies when the device is mounted. The latter is a separate issues and speaks more towards out lack of resourcing to fix the myriad of pcfs bugs. Hopefully with OpenSolaris we'll be able to get some people not on Sun's payroll to fix pcfs. mike From Michael.Bender@sun.com Mon Jun 11 16:29:30 2007 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 l5BNTTpF012958 for ; Mon, 11 Jun 2007 16:29:30 -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 l5BNRmJi020323; Tue, 12 Jun 2007 07:27:55 +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 <0JJH0010FVUJD200@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 16:27:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJH00EAUVUJHUA0@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Jun 2007 16:27:55 -0700 (PDT) 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 l5BNRtkS021475; Mon, 11 Jun 2007 16:27:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJH00301VTRDX00@fe-sfbay-10.sun.com> (original mail from Michael.Bender@Sun.COM); Mon, 11 Jun 2007 16:27:55 -0700 (PDT) Received: from sunray3.SFBay.Sun.COM ([10.6.102.113]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJH0095WVUH1V70@fe-sfbay-10.sun.com>; Mon, 11 Jun 2007 16:27:54 -0700 (PDT) Date: Mon, 11 Jun 2007 16:27:53 -0700 From: Michael Bender Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18029.15713.142967.593236@gargle.gargle.HOWL> Sender: Michael.Bender@sun.com To: James Carlson Cc: Glenn Faden , Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Ashish Joshi Reply-to: Michael.Bender@sun.com Message-id: <466DDA79.7060509@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.5pre (X11/20070601) Status: RO Content-Length: 2473 James Carlson wrote: > Glenn Faden writes: >> Whenever possible we should avoid creating devices in non-global zones. >> Unfortunately, it is possible to panic the kernel from a non-global zone >> if a root process has access to the raw device while it is >> simultaneously mounted as a file system. If you scribble over the >> mounted filesystem you can cause a panic. It is critical to our security >> story to assert that a root process in a non-global zone cannot crash >> the kernel or other zones. > > If the inserted device has no recognizable file system on it, or if > the one we recognize cannot be mounted, then we create a device node > in the zone. If it can be mounted, then only the mount point is > inserted in the zone for security reasons. > > But how can this be a complete answer? If the user inserts either a > blank medium or a device with an intentionally damaged file system, he > gets a device node. He can then mount it, scribble on it, and torch > the system. If a mounted filesystem can torch the system, that's a bug in the filesystem code and that needs to be fixed. > Did I miss something? > >> Again, that is not the subject of this case. This is about supporting >> device allocation in zones by Sun Ray software. If device allocation in >> standard Solaris is actually important to customers, we could extend the >> functionality in standard Solaris. However, I think that would done >> differently; probably based on HAL and the GNOME Removeable Drives and >> Media application. > > It'd be nice if this corner of the world weren't baroque. The only > thing that keeps my hand away from the derail lever is the lack of Sun > Ray engagement in the ARC; I have little expectation that a full > review would be productive. Huh, that's an interesting statement, James. What does Sun Ray have to do with this specific case and with how TX handles device allocation? We're one of the consumers of these interfaces (and in the process of our work I've found deficiencies that the TX team have addressed, hence this case), but any multi-user, multi-desktop environment would have run into these same issues - think Xterms with USB ports, multi-headed systems with a separate user on each head and with each head having dedicated USB ports, that type of device usage model. I'm also not so sure what you mean by "baroque" - are you referring to the HAL and GNOME bits? Could you clarify your statement please? thanks, mike From Glenn.Faden@sun.com Mon Jun 11 18:18:18 2007 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 l5C1IIQ2018868 for ; Mon, 11 Jun 2007 18:18:18 -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 l5C1GIq9059406; Mon, 11 Jun 2007 19:16:18 -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 <0JJI00G0F0VTUD00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 18:16:41 -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 <0JJI00DKQ0VRQX10@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 18:16:40 -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 l5C1GdB4029989; Mon, 11 Jun 2007 18:16:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJI004010UI5J00@fe-sfbay-09.sun.com> (original mail from Glenn.Faden@Sun.COM); Mon, 11 Jun 2007 18:16:39 -0700 (PDT) Received: from lockbox.Eng.Sun.COM ([129.146.108.200]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJI00NS00VR2NA0@fe-sfbay-09.sun.com>; Mon, 11 Jun 2007 18:16:39 -0700 (PDT) Date: Mon, 11 Jun 2007 18:10:31 -0700 From: Glenn Faden Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <8DBBA7FC-FF74-491A-B551-295C19A7B496@Sun.COM> Sender: Glenn.Faden@sun.com To: Bart Blanquart Cc: James Carlson , Scott Rotondo , Gary Winiger , rampart , PSARC-EXT@sun.com, Michael Bender , Ashish Joshi Message-id: <466DF287.1070200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466D9372.6090104@sun.com> <8DBBA7FC-FF74-491A-B551-295C19A7B496@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070312) Status: RO Content-Length: 1750 Bart Blanquart wrote: >> We have other requests coming from our customers to have a per-user >> fine-grained policy of whether they can do read-only or read-write >> mounts. The current design supports this because the authorizations >> for each device are configurable and extensible. We can create >> separate authorizations for read-only and read-write mounts, and >> assign one or the other to individual users. The device_clean script >> can check the authorizations (using auths(1)) and set the appropriate >> mount options. > > Is there a policy documented on what authorization names are usable > (i.e. if customers add finer-grained authorizations following the > naming examples they may end up with things like > solaris.device.cdrom.ro/solaris.device.cdrom.rw/...) so that there > won't be conflicts with (similar) authorizations we may add later? > > (auth_attr(4) implies that another top level name-space should be used > instead of 'solaris.', but that seems somewhat unfortunate, as it > prevents solaris.* or solaris.device.* from having the expected effect). Other than what the man page says, there is no policy. I agree that using a prefix other than solaris is more work since it won't be covered by solaris.*. > > Regarding the use of auths(1) in scripts: it currently seems to be > unsuited for that (even though the man-page recommends this use), as > its output is not guaranteed to contain the complete authorization > name (e.g. auths output as root is "solaris.*", so grepping for > "solaris.device.something" won't give the expected result); CR 6251549 > documents this. I agree that checking authorizations is a bit complicated in a shell script since you have to process the wild cards. --Glenn From scott.rotondo@sun.com Mon Jun 11 21:12:52 2007 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 l5C4CqAr021764 for ; Mon, 11 Jun 2007 21:12:52 -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 l5C4BL2t012119; Mon, 11 Jun 2007 21:11:21 -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 <0JJI00C018YWGL00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 21:11:20 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJI00DLA8YWQVB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Jun 2007 21:11:20 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5C4BJ81001086; Mon, 11 Jun 2007 21:11:19 -0700 (PDT) Received: from [10.7.251.213] (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l5C4BHO10524; Mon, 11 Jun 2007 21:11:17 -0700 (PDT) Date: Mon, 11 Jun 2007 22:11:08 -0700 From: Scott Rotondo Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <4669F1C1.8020000@sun.com> To: Glenn Faden Cc: James Carlson , Ashish Joshi , Gary Winiger , PSARC-ext@sun.com, rampart , Michael Bender Message-id: <466E2AEC.9020902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 2448 Glenn Faden wrote: > Scott Rotondo wrote: >> >> It seems to me that allocate should create the device nodes regardless >> of whether a file system was mounted, and therefore a single exit >> status for success is sufficient. Even if I mounted a file system at >> allocation time, I should be able to unmount it and access the device >> node directly without deallocating first. Doesn't that match how it >> works in the global zone? > First of all, the design of device allocation in TX is not the subject > of this fast track. TX has always mounted the allocated device without > creating a device node in the non-global zone. This case is only about > providing better feedback to what is going on so that Sun Ray software > can work more reliably. The design of device allocation isn't part of this case, but it's being used to justify the multiple "successful" exit codes, and that is part of this case. Here's a suggestion: Assuming that the device_clean scripts run with sufficient privilege to do so, let them create the device nodes. The script can always create device nodes, or never, or only when mount fails. Or you can implement other unusual policies we haven't thought of yet. In any case, you only need one exit status for whatever the script thinks is "success" because there is no further action for the device allocation code to take. >> >> A more basic question: This case mentions the fact that mounting file >> systems during allocation is unique to TX, but I believe the >> difference is simply due to historical accident. Wouldn't it make >> sense to provide this feature to all Solaris users of device >> allocation, regardless of whether TX is enabled or not? > Again, that is not the subject of this case. This is about supporting > device allocation in zones by Sun Ray software. If device allocation in > standard Solaris is actually important to customers, we could extend the > functionality in standard Solaris. However, I think that would done > differently; probably based on HAL and the GNOME Removeable Drives and > Media application. As you know, I would very much like to see a grand unified implementation for device allocation that works with or without TX and plays well with logindevperm, volume management, and Gnome's removable media utility. It would require a certain amount of work, but I'm convinced it's feasible. But as you said, that's not this case. Scott From carlsonj@phorcys.east.sun.com Tue Jun 12 04:40:00 2007 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 l5CBdxlv000307 for ; Tue, 12 Jun 2007 04:40:00 -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 l5CBc8Wq014983; Tue, 12 Jun 2007 19:38:24 +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 <0JJI0070LTNWBB00@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 05:38:20 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJI00997TNVUXC0@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 05:38:20 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5CBcIZR005412; Tue, 12 Jun 2007 07:38:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5CBcIwu005409; Tue, 12 Jun 2007 07:38:18 -0400 (EDT) Date: Tue, 12 Jun 2007 07:38:18 -0400 From: James Carlson Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <466DDA79.7060509@sun.com> To: Michael.Bender@sun.com Cc: Glenn Faden , Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Ashish Joshi Message-id: <18030.34218.820650.19259@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466DDA79.7060509@sun.com> Status: RO Content-Length: 1052 Michael Bender writes: > Huh, that's an interesting statement, James. What does Sun Ray have to > do with this specific case and with how TX handles device allocation? To be honest, I cannot tell. I know that two of the three separate issues presented are related to Sun Ray operation, and assumptions it makes about device allocation. I can't tell if the middle one is also related or if it's just a bonus issue. > I'm also not so sure what you mean by "baroque" - are you referring to > the HAL and GNOME bits? Could you clarify your statement please? I'm referring (again) to the use of multiple success codes. I think that's grotesque. As I said before (though Scott Rotondo disagreed), I'm willing to give up if it makes sense to the consumers. I'm not willing to redesign it here, especially given the resistance. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From scott.rotondo@sun.com Tue Jun 12 10:10:50 2007 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 l5CHAn1s009766 for ; Tue, 12 Jun 2007 10:10:50 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5CH9Goc020509; Tue, 12 Jun 2007 18:09:18 +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 <0JJJ0080N8ZFD500@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jun 2007 10:09:15 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJJ0067B8ZEYP40@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jun 2007 10:09:14 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5CH9DlI000339; Tue, 12 Jun 2007 10:09:13 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l5CH99O15326; Tue, 12 Jun 2007 10:09:13 -0700 (PDT) Date: Tue, 12 Jun 2007 10:09:09 -0700 From: Scott Rotondo Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18030.34218.820650.19259@gargle.gargle.HOWL> To: James Carlson Cc: Michael.Bender@sun.com, Glenn Faden , Gary Winiger , rampart , PSARC-ext@sun.com, Ashish Joshi Message-id: <466ED335.3010407@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466DDA79.7060509@sun.com> <18030.34218.820650.19259@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0b2 (X11/20070326) Status: RO Content-Length: 712 James Carlson wrote: > Michael Bender writes: >> I'm also not so sure what you mean by "baroque" - are you referring to >> the HAL and GNOME bits? Could you clarify your statement please? > > I'm referring (again) to the use of multiple success codes. I think > that's grotesque. > > As I said before (though Scott Rotondo disagreed), I'm willing to give > up if it makes sense to the consumers. I'm not willing to redesign it > here, especially given the resistance. At this point, I'm done. I've raised my objections and made my suggestions for improvement. I still think the multiple success codes are a bad idea, but I'll leave it to the ARC to decide how important it is to fix that issue. Scott From gww@eng.sun.com Tue Jun 12 14:58:54 2007 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 l5CLwsxD019143 for ; Tue, 12 Jun 2007 14:58:54 -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 l5CLvN5w019446 for <@newsunmail1brm.central.sun.com:PSARC-ext@sun.com>; Tue, 12 Jun 2007 14:57:23 -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 <0JJJ00205MBNSH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 12 Jun 2007 15:57:23 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJJ00N7WMBM3E20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 12 Jun 2007 15:57:22 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5CLvLLe027892; Tue, 12 Jun 2007 14:57:21 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5CLxual011000; Tue, 12 Jun 2007 14:59:56 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5CLxtOE010999; Tue, 12 Jun 2007 14:59:55 -0700 (PDT) Date: Tue, 12 Jun 2007 14:59:55 -0700 (PDT) From: Gary Winiger Subject: Restart 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-ext@sun.com Cc: ashish.joshi@sun.com, craig.payne@sun.com, gww@sac.sfbay.sun.com Message-id: <200706122159.l5CLxtOE010999@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 7195 > I'm moving this case to waiting need spec. Try as I have, > the project team has still failed to provide a full spec. > I believe the same to be true of the approved PSARC/2005/691. > When the project team provides a full spec, including missing > information from PSARC/2005/691, I'll restart the case. > > I believe the crux of the issues are in the spec, not the > architecture. I'd like to restart this case. The project team has provided updated interfaces, in particular list_devices(1) exports the "-a" and "-w" options for providing a stable form of output. That form is a list key=value pairs. This work was really part of PSARC/2005/691 Trusted Extensions for Device Allocation, however never exposed nor documented there. It represents an Uncommitted interface. Three ON non-consolidation consumers of the device allocation commands have been identified when TX is configured: Trusted CDE, Trusted JDS, and SunRay. A prototype contract and an updated list_devices(1) man page are in the case directory. Again, '~' in the first column represent missing changes from 2005/691. '+', '-', and '|' represent changes for this case. I've only included the new changes relevant to -a and -w below. Other than SunRay identifying the need for the "class" and "xdpy" key words, this case is unrelated to SunRay. SunRay is just one consumer. I believe the issue of device_clean(5) multiple success codes seems to have converged with no change. There is general agreement that device allocation in Solaris without TX needs to be improved, however that's not this case. I've extended the timer to 15 June 2007. Gary.. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ list_devices(1): ~~~~~~~~~~~~~~~~~~~~~~ SYNOPSIS ~ list_devices [-s] [-U uid] [-z zonename] [-a [-w]] | [-l | -n | -u] [-c dev-class | device] The following options are supported if the system is config- ured with Trusted Extensions: -a Lists attributes like authorizations, clean- ing programs and labels associated with a ~ device. The list is a single line of semicolon ~ (;) separated key=value pairs per device in ~ the format: ~ device=;type=;\ ~ auths=;clean=;\ ~ ;\ ~ files= ~ ~ where ~ device-attributes is the contents of the reserved1 ~ field of device_allocate(4). (Note, that field is ~ colon (:) separated.) See device_allocate(4) for ~ a description of these attributes and their format. ~ ~ The -a output has the following keys: ~ ~ device Specifies device name. Value is ~ device-name as described in ~ device_allocate(4). ~ type Specifies device type. Value is ~ device-type as described in ~ device_allocate(4). ~ auths Specifies list of authorizations. ~ Value is auths as described in ~ device_allocate(4). ~ clean Specifies device cleaning script. ~ Value is device-exec as described ~ in device_allocate(4). ~ files Specifies device file paths. Value ~ is device-list as described in ~ device_maps(4). -d [dev-type] Displays the system-supplied default attri- butes for the device types managed by device allocation. If dev-type is specified, it lists the default attributes for only that device type. ~ -w This option may be used along with -a to list ~ the current owner of the device as the key value ~ pair owner= . Value is the uid of the ~ current owner of the device. If the device ~ is unallocated, value is "/FREE". If the device ~ is in error state, value is "/ERROR". This option ~ also suppresses any diagnostic output. -z zonename When specified with the -l option, lists only those non-allocated devices whose label range includes the label of the zonename, and of the allocated devices, only those that are allocated at the same label as that of zonename. When specified with the -n option, lists only those non-allocated devices whose label range includes the label of the zonename. When specified with the -u option, lists only those devices that are allocated at the same label as that of zonename. EXAMPLES ~ Example 1 Listing all devices available to the caller for ~ allocation. ~ % list_devices -l ~ device: audio type: audio \ ~ files: /dev/audio /dev/audioctl /dev/sound/0 /dev/sound/0ctl ~ ~ Example 2 On a system configured with Trusted Extensions, listing ~ attributes of all devices available to the caller for ~ allocation. ~ ~ % list_devices -al ~ device=audio1;type=audio;\ ~ auths=solaris.device.allocate;\ ~ clean=/etc/security/lib/audio_clean;\ ~ minlabel=admin_low:maxlabel=admin_high;\ ~ files=/dev/audio1 /dev/audio1ctl /dev/sound/1 /dev/sound/1ctl ~ ~ Example 3: On a system configured with Trusted Extensions, listing ~ attributes including the device owner of all devices ~ allocated to the user. ~ ~ % list_devices -auw ~ device=audio2;type=audio;auths=solaris.device.allocate;\ ~ clean=/etc/security/lib/audio_clean;\ ~ minlabel=admin_low:maxlabel=admin_high:zone=public;\ ~ owner=1234;\ ~ files=/dev/audio2 /dev/audio2ctl /dev/sound/2 /dev/sound/2ctl EXIT STATUS The following exit values are returned: | 0 Success. + 20 No entry for specified device. + Other values General error ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ___________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWcsu | |_____________________________|_____________________________| | Interface Stability | See below. | |_____________________________|_____________________________| | The invocation is Uncommitted. The options are Uncommitted. | The output of the -a and -w options is Uncommitted. All other | output is Not-an-interface. From Michael.Bender@sun.com Tue Jun 12 15:31:21 2007 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 l5CMVLUa020967 for ; Tue, 12 Jun 2007 15:31:21 -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 l5CMTL6J036170; Tue, 12 Jun 2007 16:29:23 -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 <0JJJ00F11NTPWN00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Jun 2007 15:29:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJJ001S6NTLS570@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Jun 2007 15:29:45 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5CMTj7R021056; Tue, 12 Jun 2007 15:29:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JJJ00M01NHFX100@fe-sfbay-09.sun.com> (original mail from Michael.Bender@Sun.COM); Tue, 12 Jun 2007 15:29:45 -0700 (PDT) Received: from [192.9.64.105] ([24.23.213.144]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JJJ005SCNT7J180@fe-sfbay-09.sun.com>; Tue, 12 Jun 2007 15:29:32 -0700 (PDT) Date: Tue, 12 Jun 2007 15:29:37 -0700 From: Michael Bender/MBP Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates In-reply-to: <18030.34218.820650.19259@gargle.gargle.HOWL> Sender: Michael.Bender@sun.com To: James Carlson Cc: Glenn Faden , Scott Rotondo , Gary Winiger , rampart , PSARC-ext@sun.com, Ashish Joshi Reply-to: Michael.Bender@sun.com Message-id: <466F1E51.9070309@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706062318.l56NIG8U026038@sac.sfbay.sun.com> <18023.63916.967995.441199@gargle.gargle.HOWL> <46685090.9070709@sun.com> <18024.28068.426137.745161@gargle.gargle.HOWL> <4669E2D4.8040700@sun.com> <4669F1C1.8020000@sun.com> <18029.15713.142967.593236@gargle.gargle.HOWL> <466DDA79.7060509@sun.com> <18030.34218.820650.19259@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) Status: RO Content-Length: 1496 James Carlson wrote: > Michael Bender writes: >> Huh, that's an interesting statement, James. What does Sun Ray have to >> do with this specific case and with how TX handles device allocation? > > To be honest, I cannot tell. I know that two of the three separate > issues presented are related to Sun Ray operation, and assumptions it > makes about device allocation. I can't tell if the middle one is also > related or if it's just a bonus issue. Sun Ray doesn't make assumptions about device allocation, I asked the TX team what the DA requirements were and we worked together to come up with how to get Sun Ray to work in a TX environment. >> I'm also not so sure what you mean by "baroque" - are you referring to >> the HAL and GNOME bits? Could you clarify your statement please? > > I'm referring (again) to the use of multiple success codes. I think > that's grotesque. Well, how about if we make '0' the error code, and all the non-zero codes success codes ;-)? Anyway, does it really matter as long as it is all documented so that both the supplier and the consumer agree on what code means what? We're not talking about an interface that will be used by a lot of people, so expending a lot of effort on getting it "just right" doesn't seem to be a very good use of time. > As I said before (though Scott Rotondo disagreed), I'm willing to give > up if it makes sense to the consumers. I'm not willing to redesign it > here, especially given the resistance. OK, thanks. mike From gww@eng.sun.com Wed Jun 13 13:53:20 2007 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 l5DKrK8H022873 for ; Wed, 13 Jun 2007 13:53:20 -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 l5DKpmlD018639 for <@newsunmail1brm.central.sun.com:PSARC-ext@sun.com>; Wed, 13 Jun 2007 13:51:48 -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 <0JJL0060RDYA4T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jun 2007 14:51:46 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJL00I2TDY9ULA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jun 2007 14:51:45 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5DKpi6w008241; Wed, 13 Jun 2007 13:51:44 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5DKsKir012907; Wed, 13 Jun 2007 13:54:20 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5DKsKNB012906; Wed, 13 Jun 2007 13:54:20 -0700 (PDT) Date: Wed, 13 Jun 2007 13:54:20 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-EXT@sun.com, gww@sac.sfbay.sun.com Cc: ashish.joshi@sun.com Message-id: <200706132054.l5DKsKNB012906@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 186 With nose holding for multiple success returns and functionality mismatches between Solaris and Solaris with Trusted Extensions, this case was approved at today's PSARC meeting. Gary.. From gww@eng.sun.com Tue Jun 19 12:20:50 2007 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 l5JJKosD018907 for ; Tue, 19 Jun 2007 12:20:50 -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 l5JJJ86V028270 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Tue, 19 Jun 2007 12:19:13 -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 <0JJW002WGDO0DE00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 19 Jun 2007 13:19:12 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJW00HLRDNXQP90@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 19 Jun 2007 13:19:09 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5JJJ8JZ024743; Tue, 19 Jun 2007 12:19:08 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5JJLrbC022007; Tue, 19 Jun 2007 12:21:53 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5JJLqxW022006; Tue, 19 Jun 2007 12:21:52 -0700 (PDT) Date: Tue, 19 Jun 2007 12:21:52 -0700 (PDT) From: Gary Winiger Subject: contract-02 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-EXT@sun.com, gww@eng.sun.com, gww@sac.sfbay.sun.com Cc: ashish.joshi@sun.com Message-id: <200706191921.l5JJLqxW022006@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 115 Based on the approved prototype contract, I have executed contract-02 for use of these interfaces by TCDE. Gary.. From gww@eng.sun.com Wed Jun 20 13:11:04 2007 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 l5KKB48I028910 for ; Wed, 20 Jun 2007 13:11:04 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5KK9GaO024132 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 20 Jun 2007 21:09:24 +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 <0JJY00D01ANL7K00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 20 Jun 2007 13:09:21 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJY00739ANL9F90@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 20 Jun 2007 13:09:21 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5KK9KWQ013851; Wed, 20 Jun 2007 13:09:20 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5KKC6pv023993; Wed, 20 Jun 2007 13:12:06 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5KKC6vw023992; Wed, 20 Jun 2007 13:12:06 -0700 (PDT) Date: Wed, 20 Jun 2007 13:12:06 -0700 (PDT) From: Gary Winiger Subject: contract-01 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-EXT@sun.com, gww@eng.sun.com, gww@sac.sfbay.sun.com Cc: ashish.joshi@sun.com Message-id: <200706202012.l5KKC6vw023992@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 116 Based on the approved prototype contract, I have executed contract-01 for use of these interfaces by TJDS. Gary.. From gww@eng.sun.com Wed Jun 20 15:25:21 2007 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 l5KMPKV3005275 for ; Wed, 20 Jun 2007 15:25:20 -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 l5KMNYcJ023220 for <@newsunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Thu, 21 Jun 2007 06:23:40 +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 <0JJY00N0TGVD1E00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 20 Jun 2007 16:23:37 -0600 (MDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJY00KLOGUZOK10@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 20 Jun 2007 16:23:24 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5KMNMGR000691; Wed, 20 Jun 2007 15:23:22 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5KMQ9HB024237; Wed, 20 Jun 2007 15:26:09 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5KMQ8EC024236; Wed, 20 Jun 2007 15:26:08 -0700 (PDT) Date: Wed, 20 Jun 2007 15:26:08 -0700 (PDT) From: Gary Winiger Subject: contract-04 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-EXT@sun.com, gww@eng.sun.com Cc: ashish.joshi@sun.com Message-id: <200706202226.l5KMQ8EC024236@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 135 Based on the approved prototype contract, I have executed contract-04 for use of these interfaces by usb components of SunRay. Gary.. From gww@eng.sun.com Thu Jun 28 12:25:11 2007 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 l5SJPAOI016335 for ; Thu, 28 Jun 2007 12:25:10 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5SJNOWE016600 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 28 Jun 2007 20:23:25 +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 <0JKD00M011V0LX00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 28 Jun 2007 12:23:24 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKD00L511UZYB80@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 28 Jun 2007 12:23:23 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5SJNNCw011255; Thu, 28 Jun 2007 12:23:23 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5SJQKIi003247; Thu, 28 Jun 2007 12:26:20 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5SJQKHR003246; Thu, 28 Jun 2007 12:26:20 -0700 (PDT) Date: Thu, 28 Jun 2007 12:26:20 -0700 (PDT) From: Gary Winiger Subject: contract-03 2007/332 Trusted Extensions for Device Allocation Updates To: PSARC-EXT@sun.com, gww@eng.sun.com Cc: ashish.joshi@sun.com Message-id: <200706281926.l5SJQKHR003246@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 142 Based on the approved prototype contract, I have executed contract-03 for use of these interfaces by multimedia components of SunRay. Gary..