From markcarl@sac.sfbay.sun.com Tue Nov 4 05:31:17 2008 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 mA4DVGv0015058 for ; Tue, 4 Nov 2008 05:31:17 -0800 (PST) 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 mA4DVF9v018112; Tue, 4 Nov 2008 06:31:16 -0700 (MST) 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 <0K9T0001N9K4E600@brm-avmta-1.central.sun.com>; Tue, 04 Nov 2008 06:31:16 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00DWH9K3UU50@brm-avmta-1.central.sun.com>; Tue, 04 Nov 2008 06:31:16 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA4DVDqm048792; Tue, 04 Nov 2008 05:31:13 -0800 (PST) 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 mA4DVBr6015053; Tue, 04 Nov 2008 05:31:11 -0800 (PST) Received: (from markcarl@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mA4DVBiU015049; Tue, 04 Nov 2008 05:31:11 -0800 (PST) Date: Tue, 04 Nov 2008 05:31:11 -0800 (PST) From: Mark Carlson Subject: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] To: LSARC-ext@sun.com Cc: David.Zhang@sun.com, Xiao.Li@sun.com Message-id: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8942 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Sg3 utilities 1.25 1.2. Name of Document Author/Supplier: Author: Xiao Li 1.3 Date of This Document: 04 November, 2008 2. Project Summary 2.1. Project Description This project introduces the package of Sg3 utilites 1.25 into the SFW consolidation. 4. Technical Description The sg3_utils package contains utilities that send SCSI commands to devices. As well as devices on transports traditionally associated with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and the SCSI Parallel Interface(SPI)) and many other devices use SCSI command sets. ATAPI cd/dvd drives and SATA disks that connect via a translation layer or a bridge device are examples of devices that use SCSI command sets. There are about 32 command line utilities inside this package. Command name Notes ============ =================================================== sg_get_config fetch features and profiles of a cd/dvd drive and/or its current media sg_ident default is to report (fetch) the device identifier. With the '--set' option a new identifier is sent to the device. sg_inq fetch standard response, VPD pages or version descriptors. Also can perform IDENTIFY (PACKET) DEVICE ATA command. VPD page decoding also performed by sg_vpd and sdparm. sg_logs fetch log sense pages, decode standard and some vendor pages sg_luns fetch luns reported by a device (lun 0 or "well known lu") sg_modes fetch mode pages (output mainly in hex, to decode output use sdparm) sg_opcodes fetch supported SCSI commands or supported task management functions sg_persist control persistent reservations and report reservation status sg_prevent control media removal, mainly for those SCSI devices which have removable media (e.g. CD/DVD and tape drives) sg_raw send user supplied cdb sg_rdac display or modify RDAC redundant controller mode page sg_read_buffer read descriptors or data sg_read_long read data from given lba which includes the block and ECC data. sg_readcap fetch the number of blocks and the individual block size for disks and CD/DVD media sg_reassign reassign a lba from one sector on a disk (typically damaged) to a new (spare) sector. User data copied if it is recoverable. sg_requests fetch sense data from the given device. Modern uses include getting a progress indication (e.g. during a format) or finding the power condition state. sg_rmsn Relatively new command added to SPC-3. Format of response is vendor specific so this utility outputs it in hex (default) or binary. sg_rtpg Specialized for multi-ported SCSI devices where one port (or a group of them) is preferred for IO over another (or others). sg_safte fetch information from a SAF-TE processor. sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI command. sg_sat_set_features Sends ATA SET FEATURES command via SAT. sg_senddiag Issues either a default self test or a short/extended foreground/background self test. With no arguments it uses RECEIVE DIAGNOSTIC RESULTS to list all supported diagnostic pages. sg_ses Fetches status diagnostic pages from, and sends some control pages to, a SCSI Enclosure Services (SES) device. sg_start Controls the power condition state of a SCSI device. Primary use is to spin up and down SCSI disks. Can also load and eject removable media. sg_stpg Specialized for multi-ported SCSI devices where one port (or a group of them) is preferred for IO over another (or others). sg_sync Causes disk caches to be flushed to media. sg_turs Issue one or more Test Unit Ready commands. Can be used to time SCSI command overhead. sg_verify reads indicated blocks on a SCSI disks, stops on the first error found. Does not yield any data. Useful for media scans. sg_vpd Decodes standard and some vendor Vital Product Data (VPD) pages. sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from "sg_modes -r") to the SCSI device. See sdparm for another method of setting mode page parameters. sg_write_buffer write data; can be used to download firmware. sg_write_long writes to a lba, data which includes the block and ECC data. Suitable data typically fetched by prior sg_read_long utility. 5. Interfaces Exported interface Classification Interface type =============================== ============== ============== SUNWsg3utils Uncommitted Package name /usr/bin/sg_get_config Uncommitted Command /usr/bin/sg_ident Uncommitted Command /usr/bin/sg_inq Uncommitted Command /usr/bin/sg_logs Uncommitted Command /usr/bin/sg_luns Uncommitted Command /usr/bin/sg_modes Uncommitted Command /usr/bin/sg_opcodes Uncommitted Command /usr/bin/sg_persist Uncommitted Command /usr/bin/sg_prevent Uncommitted Command /usr/bin/sg_raw Uncommitted Command /usr/bin/sg_rdac Uncommitted Command /usr/bin/sg_read_buffer Uncommitted Command /usr/bin/sg_read_long Uncommitted Command /usr/bin/sg_readcap Uncommitted Command /usr/bin/sg_reassign Uncommitted Command /usr/bin/sg_requests Uncommitted Command /usr/bin/sg_rmsn Uncommitted Command /usr/bin/sg_rtpg Uncommitted Command /usr/bin/sg_safte Uncommitted Command /usr/bin/sg_sat_identify Uncommitted Command /usr/bin/sg_sat_set_features Uncommitted Command /usr/bin/sg_senddiag Uncommitted Command /usr/bin/sg_ses Uncommitted Command /usr/bin/sg_start Uncommitted Command /usr/bin/sg_stpg Uncommitted Command /usr/bin/sg_sync Uncommitted Command /usr/bin/sg_turs Uncommitted Command /usr/bin/sg_verify Uncommitted Command /usr/bin/sg_vpd Uncommitted Command /usr/bin/sg_wr_mode Uncommitted Command /usr/bin/sg_write_buffer Uncommitted Command /usr/bin/sg_write_long Uncommitted Command /usr/lib/libsgutils.so Private Symbolic link /usr/lib/libsgutils.so.1 Private Symbolic link /usr/lib/libsgutils.so.1.0.0 Private Shared library /usr/lib/libsgutils.a Private Static library /usr/lib/libsgutils.la Private Libtool library file /usr/include/scsi/sg_lib.h Uncommitted Header file /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file /usr/include/scsi/sg_cmds.h Uncommitted Header file /usr/include/scsi/sg_pt.h Uncommitted Header file /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage /usr/share/man/man8/sg_safte.8 Uncommitted Manpage /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage /usr/share/man/man8/sg_persist.8 Uncommitted Manpage /usr/share/man/man8/sg_ses.8 Uncommitted Manpage /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage /usr/share/man/man8/sg_luns.8 Uncommitted Manpage /usr/share/man/man8/sg_requests.8 Uncommitted Manpage /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage /usr/share/man/man8/sg_start.8 Uncommitted Manpage /usr/share/man/man8/sg_verify.8 Uncommitted Manpage /usr/share/man/man8/sg_modes.8 Uncommitted Manpage /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage /usr/share/man/man8/sg_ident.8 Uncommitted Manpage /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage /usr/share/man/man8/sg_inq.8 Uncommitted Manpage /usr/share/man/man8/sg_raw.8 Uncommitted Manpage /usr/share/man/man8/sg_turs.8 Uncommitted Manpage /usr/share/man/man8/sg_sync.8 Uncommitted Manpage /usr/share/man/man8/sg_logs.8 Uncommitted Manpage /usr/share/man/man8/sg_format.8 Uncommitted Manpage /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage The following additional installed files are not interface. Additional document ------------------- N/A 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Mark.Carlson@sun.com Tue Nov 4 05:33:18 2008 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 mA4DXHWe015108 for ; Tue, 4 Nov 2008 05:33:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA4DWvbd005895 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 13:33:16 GMT 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 <0K9T00L0D9NE7O00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 05:33:14 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00IIM9ND5M40@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 05:33:14 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA4DXDx3028648 for ; Tue, 04 Nov 2008 13:33:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9T00M017YAA000@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 06:33:13 -0700 (MST) Received: from Macintosh-252.local ([129.150.32.105]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T0056K9MUCEC0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 06:32:56 -0700 (MST) Date: Tue, 04 Nov 2008 06:32:53 -0700 From: "Mark A. Carlson" Subject: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> Sender: Mark.Carlson@sun.com To: LSARC-ext@sun.com Cc: David.Zhang@sun.com, Xiao.Li@sun.com Message-id: <49104F05.7070305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 9472 I am sponsoring this case for Xiao Li. I have marked it closed approved automatic based on the checklist in the case directory. -- mark > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Sg3 utilities 1.25 > 1.2. Name of Document Author/Supplier: > Author: Xiao Li > 1.3 Date of This Document: > 04 November, 2008 > > 2. Project Summary > 2.1. Project Description > > This project introduces the package of Sg3 utilites 1.25 into the > SFW consolidation. > > 4. Technical Description > > The sg3_utils package contains utilities that send SCSI commands to > devices. As well as devices on transports traditionally associated > with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and > the SCSI Parallel Interface(SPI)) and many other devices use SCSI > command sets. ATAPI cd/dvd drives and SATA disks that connect via a > translation layer or a bridge device are examples of devices that > use SCSI command sets. > There are about 32 command line utilities inside this package. > Command name Notes > ============ =================================================== > sg_get_config fetch features and profiles of a cd/dvd drive and/or > its current media > sg_ident default is to report (fetch) the device identifier. > With the '--set' option a new identifier is sent to > the device. > sg_inq fetch standard response, VPD pages or version > descriptors. Also can perform IDENTIFY (PACKET) > DEVICE ATA command. VPD page decoding also performed > by sg_vpd and sdparm. > sg_logs fetch log sense pages, decode standard and some vendor > pages > sg_luns fetch luns reported by a device (lun 0 or "well known > lu") > sg_modes fetch mode pages (output mainly in hex, to decode > output use sdparm) > sg_opcodes fetch supported SCSI commands or supported task > management functions > sg_persist control persistent reservations and report reservation > status > sg_prevent control media removal, mainly for those SCSI devices > which have removable media (e.g. CD/DVD and tape drives) > sg_raw send user supplied cdb > sg_rdac display or modify RDAC redundant controller mode page > sg_read_buffer read descriptors or data > sg_read_long read data from given lba which includes the block and > ECC data. > sg_readcap fetch the number of blocks and the individual block > size for disks and CD/DVD media > sg_reassign reassign a lba from one sector on a disk (typically > damaged) to a new (spare) sector. User data copied if > it is recoverable. > sg_requests fetch sense data from the given device. Modern uses > include getting a progress indication (e.g. during a > format) or finding the power condition state. > sg_rmsn Relatively new command added to SPC-3. Format of > response is vendor specific so this utility outputs > it in hex (default) or binary. > sg_rtpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_safte fetch information from a SAF-TE processor. > sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE > commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI > command. > sg_sat_set_features Sends ATA SET FEATURES command via SAT. > sg_senddiag Issues either a default self test or a short/extended > foreground/background self test. With no arguments it > uses RECEIVE DIAGNOSTIC RESULTS to list all supported > diagnostic pages. > sg_ses Fetches status diagnostic pages from, and sends some > control pages to, a SCSI Enclosure Services (SES) > device. > sg_start Controls the power condition state of a SCSI device. > Primary use is to spin up and down SCSI disks. Can > also load and eject removable media. > sg_stpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_sync Causes disk caches to be flushed to media. > sg_turs Issue one or more Test Unit Ready commands. Can be > used to time SCSI command overhead. > sg_verify reads indicated blocks on a SCSI disks, stops on the > first error found. Does not yield any data. Useful > for media scans. > sg_vpd Decodes standard and some vendor Vital Product Data > (VPD) pages. > sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from > "sg_modes -r") to the SCSI device. See sdparm for > another method of setting mode page parameters. > sg_write_buffer write data; can be used to download firmware. > sg_write_long writes to a lba, data which includes the block and > ECC data. Suitable data typically fetched by prior > sg_read_long utility. > 5. Interfaces > > Exported interface Classification Interface type > =============================== ============== ============== > SUNWsg3utils Uncommitted Package name > /usr/bin/sg_get_config Uncommitted Command > /usr/bin/sg_ident Uncommitted Command > /usr/bin/sg_inq Uncommitted Command > /usr/bin/sg_logs Uncommitted Command > /usr/bin/sg_luns Uncommitted Command > /usr/bin/sg_modes Uncommitted Command > /usr/bin/sg_opcodes Uncommitted Command > /usr/bin/sg_persist Uncommitted Command > /usr/bin/sg_prevent Uncommitted Command > /usr/bin/sg_raw Uncommitted Command > /usr/bin/sg_rdac Uncommitted Command > /usr/bin/sg_read_buffer Uncommitted Command > /usr/bin/sg_read_long Uncommitted Command > /usr/bin/sg_readcap Uncommitted Command > /usr/bin/sg_reassign Uncommitted Command > /usr/bin/sg_requests Uncommitted Command > /usr/bin/sg_rmsn Uncommitted Command > /usr/bin/sg_rtpg Uncommitted Command > /usr/bin/sg_safte Uncommitted Command > /usr/bin/sg_sat_identify Uncommitted Command > /usr/bin/sg_sat_set_features Uncommitted Command > /usr/bin/sg_senddiag Uncommitted Command > /usr/bin/sg_ses Uncommitted Command > /usr/bin/sg_start Uncommitted Command > /usr/bin/sg_stpg Uncommitted Command > /usr/bin/sg_sync Uncommitted Command > /usr/bin/sg_turs Uncommitted Command > /usr/bin/sg_verify Uncommitted Command > /usr/bin/sg_vpd Uncommitted Command > /usr/bin/sg_wr_mode Uncommitted Command > /usr/bin/sg_write_buffer Uncommitted Command > /usr/bin/sg_write_long Uncommitted Command > /usr/lib/libsgutils.so Private Symbolic link > /usr/lib/libsgutils.so.1 Private Symbolic link > /usr/lib/libsgutils.so.1.0.0 Private Shared library > /usr/lib/libsgutils.a Private Static library > /usr/lib/libsgutils.la Private Libtool library > file > /usr/include/scsi/sg_lib.h Uncommitted Header file > /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file > /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file > /usr/include/scsi/sg_cmds.h Uncommitted Header file > /usr/include/scsi/sg_pt.h Uncommitted Header file > /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_safte.8 Uncommitted Manpage > /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage > /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage > /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_persist.8 Uncommitted Manpage > /usr/share/man/man8/sg_ses.8 Uncommitted Manpage > /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage > /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage > /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage > /usr/share/man/man8/sg_luns.8 Uncommitted Manpage > /usr/share/man/man8/sg_requests.8 Uncommitted Manpage > /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage > /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage > /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage > /usr/share/man/man8/sg_start.8 Uncommitted Manpage > /usr/share/man/man8/sg_verify.8 Uncommitted Manpage > /usr/share/man/man8/sg_modes.8 Uncommitted Manpage > /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage > /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage > /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage > /usr/share/man/man8/sg_ident.8 Uncommitted Manpage > /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage > /usr/share/man/man8/sg_inq.8 Uncommitted Manpage > /usr/share/man/man8/sg_raw.8 Uncommitted Manpage > /usr/share/man/man8/sg_turs.8 Uncommitted Manpage > /usr/share/man/man8/sg_sync.8 Uncommitted Manpage > /usr/share/man/man8/sg_logs.8 Uncommitted Manpage > /usr/share/man/man8/sg_format.8 Uncommitted Manpage > /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage > > The following additional installed files are not interface. > > Additional document > ------------------- > N/A > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > From James.McPherson@Sun.COM Tue Nov 4 05:36:38 2008 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 mA4DacU5015355 for ; Tue, 4 Nov 2008 05:36:38 -0800 (PST) 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 mA4DacH2001983 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 05:36:38 -0800 (PST) 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 <0K9T0000J9SZR700@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 06:36:35 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00DEO9SYUV50@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 06:36:34 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA4DaYuK029717 for ; Tue, 04 Nov 2008 13:36:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9T00F019OQH600@mail-amer.sun.com> (original mail from James.McPherson@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 06:36:34 -0700 (MST) Received: from [192.168.1.10] ([220.157.71.44]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T005CT9SRCED0@mail-amer.sun.com>; Tue, 04 Nov 2008 06:36:33 -0700 (MST) Date: Tue, 04 Nov 2008 23:36:23 +1000 From: "James C. McPherson" Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> Sender: James.McPherson@Sun.COM To: Mark Carlson Cc: LSARC-ext@Sun.COM, Xiao.Li@Sun.COM, David.Zhang@Sun.COM Reply-to: James.McPherson@Sun.COM Message-id: <49104FD7.9070206@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080825) Status: RO Content-Length: 9919 Mark Carlson wrote: > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Sg3 utilities 1.25 > 1.2. Name of Document Author/Supplier: > Author: Xiao Li > 1.3 Date of This Document: > 04 November, 2008 > > 2. Project Summary > 2.1. Project Description > > This project introduces the package of Sg3 utilites 1.25 into the > SFW consolidation. > > 4. Technical Description > > The sg3_utils package contains utilities that send SCSI commands to > devices. As well as devices on transports traditionally associated > with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and > the SCSI Parallel Interface(SPI)) and many other devices use SCSI > command sets. ATAPI cd/dvd drives and SATA disks that connect via a > translation layer or a bridge device are examples of devices that > use SCSI command sets. Are these utilities going to make use of the existing features in OpenSolaris which make writing such utilities *really easy*? ie, using libscsi and libses, as well as ? Or will they be an as-close-as-possible port from other parts of the OpenSource ecosystem? James > There are about 32 command line utilities inside this package. > Command name Notes > ============ =================================================== > sg_get_config fetch features and profiles of a cd/dvd drive and/or > its current media > sg_ident default is to report (fetch) the device identifier. > With the '--set' option a new identifier is sent to > the device. > sg_inq fetch standard response, VPD pages or version > descriptors. Also can perform IDENTIFY (PACKET) > DEVICE ATA command. VPD page decoding also performed > by sg_vpd and sdparm. > sg_logs fetch log sense pages, decode standard and some vendor > pages > sg_luns fetch luns reported by a device (lun 0 or "well known > lu") > sg_modes fetch mode pages (output mainly in hex, to decode > output use sdparm) > sg_opcodes fetch supported SCSI commands or supported task > management functions > sg_persist control persistent reservations and report reservation > status > sg_prevent control media removal, mainly for those SCSI devices > which have removable media (e.g. CD/DVD and tape drives) > sg_raw send user supplied cdb > sg_rdac display or modify RDAC redundant controller mode page > sg_read_buffer read descriptors or data > sg_read_long read data from given lba which includes the block and > ECC data. > sg_readcap fetch the number of blocks and the individual block > size for disks and CD/DVD media > sg_reassign reassign a lba from one sector on a disk (typically > damaged) to a new (spare) sector. User data copied if > it is recoverable. > sg_requests fetch sense data from the given device. Modern uses > include getting a progress indication (e.g. during a > format) or finding the power condition state. > sg_rmsn Relatively new command added to SPC-3. Format of > response is vendor specific so this utility outputs > it in hex (default) or binary. > sg_rtpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_safte fetch information from a SAF-TE processor. > sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE > commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI > command. > sg_sat_set_features Sends ATA SET FEATURES command via SAT. > sg_senddiag Issues either a default self test or a short/extended > foreground/background self test. With no arguments it > uses RECEIVE DIAGNOSTIC RESULTS to list all supported > diagnostic pages. > sg_ses Fetches status diagnostic pages from, and sends some > control pages to, a SCSI Enclosure Services (SES) > device. > sg_start Controls the power condition state of a SCSI device. > Primary use is to spin up and down SCSI disks. Can > also load and eject removable media. > sg_stpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_sync Causes disk caches to be flushed to media. > sg_turs Issue one or more Test Unit Ready commands. Can be > used to time SCSI command overhead. > sg_verify reads indicated blocks on a SCSI disks, stops on the > first error found. Does not yield any data. Useful > for media scans. > sg_vpd Decodes standard and some vendor Vital Product Data > (VPD) pages. > sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from > "sg_modes -r") to the SCSI device. See sdparm for > another method of setting mode page parameters. > sg_write_buffer write data; can be used to download firmware. > sg_write_long writes to a lba, data which includes the block and > ECC data. Suitable data typically fetched by prior > sg_read_long utility. > 5. Interfaces > > Exported interface Classification Interface type > =============================== ============== ============== > SUNWsg3utils Uncommitted Package name > /usr/bin/sg_get_config Uncommitted Command > /usr/bin/sg_ident Uncommitted Command > /usr/bin/sg_inq Uncommitted Command > /usr/bin/sg_logs Uncommitted Command > /usr/bin/sg_luns Uncommitted Command > /usr/bin/sg_modes Uncommitted Command > /usr/bin/sg_opcodes Uncommitted Command > /usr/bin/sg_persist Uncommitted Command > /usr/bin/sg_prevent Uncommitted Command > /usr/bin/sg_raw Uncommitted Command > /usr/bin/sg_rdac Uncommitted Command > /usr/bin/sg_read_buffer Uncommitted Command > /usr/bin/sg_read_long Uncommitted Command > /usr/bin/sg_readcap Uncommitted Command > /usr/bin/sg_reassign Uncommitted Command > /usr/bin/sg_requests Uncommitted Command > /usr/bin/sg_rmsn Uncommitted Command > /usr/bin/sg_rtpg Uncommitted Command > /usr/bin/sg_safte Uncommitted Command > /usr/bin/sg_sat_identify Uncommitted Command > /usr/bin/sg_sat_set_features Uncommitted Command > /usr/bin/sg_senddiag Uncommitted Command > /usr/bin/sg_ses Uncommitted Command > /usr/bin/sg_start Uncommitted Command > /usr/bin/sg_stpg Uncommitted Command > /usr/bin/sg_sync Uncommitted Command > /usr/bin/sg_turs Uncommitted Command > /usr/bin/sg_verify Uncommitted Command > /usr/bin/sg_vpd Uncommitted Command > /usr/bin/sg_wr_mode Uncommitted Command > /usr/bin/sg_write_buffer Uncommitted Command > /usr/bin/sg_write_long Uncommitted Command > /usr/lib/libsgutils.so Private Symbolic link > /usr/lib/libsgutils.so.1 Private Symbolic link > /usr/lib/libsgutils.so.1.0.0 Private Shared library > /usr/lib/libsgutils.a Private Static library > /usr/lib/libsgutils.la Private Libtool library > file > /usr/include/scsi/sg_lib.h Uncommitted Header file > /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file > /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file > /usr/include/scsi/sg_cmds.h Uncommitted Header file > /usr/include/scsi/sg_pt.h Uncommitted Header file > /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_safte.8 Uncommitted Manpage > /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage > /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage > /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_persist.8 Uncommitted Manpage > /usr/share/man/man8/sg_ses.8 Uncommitted Manpage > /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage > /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage > /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage > /usr/share/man/man8/sg_luns.8 Uncommitted Manpage > /usr/share/man/man8/sg_requests.8 Uncommitted Manpage > /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage > /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage > /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage > /usr/share/man/man8/sg_start.8 Uncommitted Manpage > /usr/share/man/man8/sg_verify.8 Uncommitted Manpage > /usr/share/man/man8/sg_modes.8 Uncommitted Manpage > /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage > /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage > /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage > /usr/share/man/man8/sg_ident.8 Uncommitted Manpage > /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage > /usr/share/man/man8/sg_inq.8 Uncommitted Manpage > /usr/share/man/man8/sg_raw.8 Uncommitted Manpage > /usr/share/man/man8/sg_turs.8 Uncommitted Manpage > /usr/share/man/man8/sg_sync.8 Uncommitted Manpage > /usr/share/man/man8/sg_logs.8 Uncommitted Manpage > /usr/share/man/man8/sg_format.8 Uncommitted Manpage > /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage > > The following additional installed files are not interface. > > Additional document > ------------------- > N/A > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org -- James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog From Darren.Moffat@Sun.COM Tue Nov 4 06:24:18 2008 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 mA4EOIOg016813 for ; Tue, 4 Nov 2008 06:24:18 -0800 (PST) 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 mA4EOHZN022294 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 06:24:18 -0800 (PST) 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 <0K9T0040LC0H0Q00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 07:24:17 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00DF2C0GUU80@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 07:24:16 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA4EOFge009932 for ; Tue, 04 Nov 2008 14:24:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9T00801A7HRD00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 14:24:15 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T00387C01QC90@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 14:24:02 +0000 (GMT) Date: Tue, 04 Nov 2008 14:24:01 +0000 From: Darren J Moffat Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49104F05.7070305@sun.com> Sender: Darren.Moffat@Sun.COM To: "Mark A. Carlson" Cc: LSARC-ext@Sun.COM, Xiao.Li@Sun.COM, David.Zhang@Sun.COM Message-id: <49105B01.7030204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1000 Firstly I don't think LSARC is the appropriate ARC body to review a case about SCSI utilities I would have expected this to go to PSARC. I also don't think that this case qualifies for Self Review given the low level nature of the utilities and the possible impact of using them. How do these commands interact with the existing SCSI tools, libraries on Solaris ? Are there any risks to running these commands on devices managed by Solaris ? Do all these commands require privilege to run ? If so which privileges ? Is there an RBAC profile for them ? Shouldn't they really be in /usr/sbin rather than /usr/bin ? [ Or don't we care about that any more ? ] Is it really appropriate for this case to put header files into the already existing /usr/include/scsi/ ? > /usr/lib/libsgutils.la I didn't think we normally included libtool libraries, in fact there are none currently included in /usr/lib (at least as of snv_100) but I did fine some in /usr/sfw/lib/ -- Darren J Moffat From Joerg.Schilling@fokus.fraunhofer.de Tue Nov 4 07:11:17 2008 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 mA4FBHjW017914 for ; Tue, 4 Nov 2008 07:11:17 -0800 (PST) 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 mA4FBD0L059762; Tue, 4 Nov 2008 08:11:13 -0700 (MST) 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 <0K9T0070FE6P5I00@brm-avmta-1.central.sun.com>; Tue, 04 Nov 2008 08:11:13 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00DLVE6OUUB0@brm-avmta-1.central.sun.com>; Tue, 04 Nov 2008 08:11:12 -0700 (MST) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA4F6glh003494; Tue, 04 Nov 2008 15:11:12 +0000 (GMT) Received: from mms23es.mms.us.syntegra.com ([150.143.232.50] [150.143.232.50]) by relay23i.sun.com with ESMTP id BT-MMP-498541; Tue, 04 Nov 2008 15:11:12 +0000 (Z) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54]) by mms23es.mms.us.syntegra.com with ESMTP id BT-MMP-13294386; Tue, 04 Nov 2008 15:11:12 +0000 (Z) Received: from iron01.fraunhofer.de ([153.96.1.54] [153.96.1.54]) by relay23i.sun.com with ESMTP id BT-MMP-17144880; Tue, 04 Nov 2008 15:11:12 +0000 (Z) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by iron01.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; Tue, 04 Nov 2008 16:11:10 +0100 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id mA4FB8aa006600; Tue, 04 Nov 2008 16:11:10 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 04 Nov 2008 16:11:08 +0100 Date: Tue, 04 Nov 2008 16:11:07 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49104FD7.9070206@Sun.COM> To: markcarl@sac.sfbay.sun.com, James.McPherson@sun.com Cc: Xiao.Li@sun.com, LSARC-ext@sun.com, David.Zhang@sun.com Message-id: <4910660b.Tkt2GWlzCQHH8TQ5%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.143sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104FD7.9070206@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 04 Nov 2008 15:11:08.0279 (UTC) FILETIME=[90872070:01C93E8F] Status: RO Content-Length: 766 "James C. McPherson" wrote: > Mark Carlson wrote: > Are these utilities going to make use of the existing features > in OpenSolaris which make writing such utilities *really easy*? > > ie, using libscsi and libses, as well as ? > > Or will they be an as-close-as-possible port from other parts > of the OpenSource ecosystem? If you are interested in the OpenSource ecosystem for generic SCSI, look at cdrtools. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From gww@eng.sun.com Tue Nov 4 08:01:53 2008 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 mA4G1q31018951 for ; Tue, 4 Nov 2008 08:01:53 -0800 (PST) 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 mA4G1lFg022537 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 09:01:52 -0700 (MST) 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 <0K9T00HABGJ24H00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:01:50 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00A9NGILVJB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:01:34 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA4G1VAn056679; Tue, 04 Nov 2008 08:01:31 -0800 (PST) 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 mA4G1Ymh007968; Tue, 04 Nov 2008 08:01:34 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA4G1YE2007967; Tue, 04 Nov 2008 08:01:34 -0800 (PST) Date: Tue, 04 Nov 2008 08:01:34 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] To: LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Cc: David.Zhang@sun.com, Xiao.Li@sun.com Message-id: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 175 > /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage Perhaps I missed it, but my recollection was that there was no man8 section. Did it get reintroduced? Gary.. From Alan.Coopersmith@sun.com Tue Nov 4 08:21:09 2008 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 mA4GL9W3019253 for ; Tue, 4 Nov 2008 08:21:09 -0800 (PST) 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 mA4GL8gW012619 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 08:21:09 -0800 (PST) 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 <0K9T00I0XHF8ZZ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:21:08 -0800 (PST) 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 <0K9T00AFAHF6VJE0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:21:06 -0800 (PST) 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 mA4GL6Sr002456 for ; Tue, 04 Nov 2008 08:21:06 -0800 (PST) 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 <0K9T00C01CSJAG00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:21:06 -0800 (PST) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T0092ZHEPSZ30@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 04 Nov 2008 08:20:50 -0800 (PST) Date: Tue, 04 Nov 2008 08:20:49 -0800 From: Alan Coopersmith Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49104F05.7070305@sun.com> Sender: Alan.Coopersmith@sun.com To: "Mark A. Carlson" Cc: LSARC-ext@sun.com, David.Zhang@sun.com, Xiao.Li@sun.com Message-id: <49107661.1040401@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1672 Mark A. Carlson wrote: > I am sponsoring this case for Xiao Li. I have marked it closed approved > automatic based on the checklist in the case directory. The answers to this section of the checklist do not agree with the exported interfaces table, and if answered correctly, would be "ARC review required". > 3.2 Exported Libraries > Are libraries being delivered by this project? > [ ] Yes > [x] No - continue with next section (section 3.3) > > Are 64-bit versions of the libraries being delivered? > [ ] Yes > [ ] No - ARC review required > > Are static versions of the libraries being delivered? > [ ] Yes - ARC review required > [ ] No >> Exported interface Classification Interface type >> =============================== ============== ============== >> /usr/lib/libsgutils.so Private Symbolic link >> /usr/lib/libsgutils.so.1 Private Symbolic link >> /usr/lib/libsgutils.so.1.0.0 Private Shared library >> /usr/lib/libsgutils.a Private Static library >> /usr/lib/libsgutils.la Private Libtool library >> file If this is indeed a private library, then not having a 64-bit version is acceptable, but delivering .a & .la files is not. (If no one else will link with them, why would they be needed? Even if it's public, delivering .la files is unacceptable as it causes programs built using libtool to link incorrectly. If it's private, why is it in /usr/lib?) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Tue Nov 4 08:22:38 2008 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 mA4GMctf019318 for ; Tue, 4 Nov 2008 08:22:38 -0800 (PST) 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 mA4GMYRx023332 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 4 Nov 2008 08:22:38 -0800 (PST) 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 <0K9T00B07HHPNS00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 04 Nov 2008 09:22:37 -0700 (MST) 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 <0K9T00AZSHHO6910@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 04 Nov 2008 09:22:37 -0700 (MST) 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 mA4GMaXY002664 for ; Tue, 04 Nov 2008 08:22:36 -0800 (PST) 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 <0K9T00M01HCG1X00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 04 Nov 2008 08:22:36 -0800 (PST) Received: from [10.6.102.118] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T00LDOHHE8910@fe-sfbay-09.sun.com>; Tue, 04 Nov 2008 08:22:26 -0800 (PST) Date: Tue, 04 Nov 2008 08:22:26 -0800 From: Alan Coopersmith Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> Sender: Alan.Coopersmith@sun.com To: Gary Winiger Cc: LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com, David.Zhang@sun.com, Xiao.Li@sun.com Message-id: <491076C2.7000800@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 440 Gary Winiger wrote: >> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage > > Perhaps I missed it, but my recollection was that there was > no man8 section. Did it get reintroduced? Only as bugs by projects which fail to correctly deliver admin man pages under the SysV section 1m instead of the BSD section 8. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From David.Zhang@Sun.Com Wed Nov 5 00:17:11 2008 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 mA58HBI2008910 for ; Wed, 5 Nov 2008 00:17:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA58H3E8026647 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 00:17:10 -0800 (PST) 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 <0K9U00M03POKW500@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 00:17:08 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9U00IA2POJBV60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 00:17:08 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA58H7ug008253 for ; Wed, 05 Nov 2008 08:17:07 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9U00701PCNW500@fe-emea-10.sun.com> (original mail from David.Zhang@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 08:17:07 +0000 (GMT) Received: from [129.158.148.48] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9U00M8CPO4PXC0@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 08:17:00 +0000 (GMT) Date: Wed, 05 Nov 2008 16:16:51 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49105B01.7030204@Sun.COM> Sender: David.Zhang@Sun.Com To: Darren J Moffat Cc: "Mark A. Carlson" , LSARC-ext@Sun.Com, Xiao.L@Sun.Com Message-id: <49115673.6020002@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_+tAHOdSMZ5r4tgTTDCKM8g)" X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> <49105B01.7030204@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1659 This is a multi-part message in MIME format. --Boundary_(ID_+tAHOdSMZ5r4tgTTDCKM8g) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Add xiao.l@sun.com into this email loop. On 11/04/08 22:24, Darren J Moffat wrote: > Firstly I don't think LSARC is the appropriate ARC body to review a > case about SCSI utilities I would have expected this to go to PSARC. > I also don't think that this case qualifies for Self Review given the > low level nature of the utilities and the possible impact of using them. > > How do these commands interact with the existing SCSI tools, libraries > on Solaris ? Are there any risks to running these commands on > devices managed by Solaris ? > > Do all these commands require privilege to run ? If so which > privileges ? Is there an RBAC profile for them ? > > Shouldn't they really be in /usr/sbin rather than /usr/bin ? [ Or > don't we care about that any more ? ] > > Is it really appropriate for this case to put header files into the > already existing /usr/include/scsi/ ? > > > /usr/lib/libsgutils.la > > I didn't think we normally included libtool libraries, in fact there > are none currently included in /usr/lib (at least as of snv_100) but I > did fine some in /usr/sfw/lib/ > > -- > Darren J Moffat --Boundary_(ID_+tAHOdSMZ5r4tgTTDCKM8g) Content-type: text/x-vcard; name=David_Zhang.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=David_Zhang.vcf begin:vcard fn:David Zhang n:Zhang;David email;internet:David.Zhang@Sun.COM tel;work:84341 version:2.1 end:vcard --Boundary_(ID_+tAHOdSMZ5r4tgTTDCKM8g)-- From David.Zhang@sun.com Wed Nov 5 00:28:56 2008 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 mA58SttN009059 for ; Wed, 5 Nov 2008 00:28:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA58SqKu017023 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 08:28:54 GMT 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 <0K9U00F01Q85BQ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 01:28:53 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9U00C03Q84Z520@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 01:28:53 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA58Sp1U013109 for ; Wed, 05 Nov 2008 08:28:51 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9U00M01PRW3100@fe-emea-09.sun.com> (original mail from David.Zhang@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 08:28:51 +0000 (GMT) Received: from [129.158.148.48] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9U002PMQ7QN8E0@fe-emea-09.sun.com>; Wed, 05 Nov 2008 08:28:42 +0000 (GMT) Date: Wed, 05 Nov 2008 16:28:37 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <491076C2.7000800@sun.com> Sender: David.Zhang@sun.com To: Alan Coopersmith Cc: Gary Winiger , LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com, Xiao.L@sun.com Message-id: <49115935.1020401@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7uqwmOCLvhA90GpENw1zYQ)" X-PMX-Version: 5.4.1.325704 References: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> <491076C2.7000800@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 2226 This is a multi-part message in MIME format. --Boundary_(ID_7uqwmOCLvhA90GpENw1zYQ) Content-type: multipart/alternative; boundary="Boundary_(ID_Lv3b9MgVSZLnew/wyvtg7g)" --Boundary_(ID_Lv3b9MgVSZLnew/wyvtg7g) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Add xiao.l@sun.com into this email loop. On 11/05/08 00:22, Alan Coopersmith wrote: > Gary Winiger wrote: > >>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >>> >> Perhaps I missed it, but my recollection was that there was >> no man8 section. Did it get reintroduced? >> > > Only as bugs by projects which fail to correctly deliver admin man pages > under the SysV section 1m instead of the BSD section 8. > > --Boundary_(ID_Lv3b9MgVSZLnew/wyvtg7g) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Add xiao.l@sun.com into this email loop.

On 11/05/08 00:22, Alan Coopersmith wrote: 
Gary Winiger wrote:
  
    /usr/share/man/man8/sg_read_long.8	Uncommitted	Manpage
      
	Perhaps I missed it, but my recollection was that there was
	no man8 section.  Did it get reintroduced?
    

Only as bugs by projects which fail to correctly deliver admin man pages
under the SysV section 1m instead of the BSD section 8.

--Boundary_(ID_Lv3b9MgVSZLnew/wyvtg7g)-- --Boundary_(ID_7uqwmOCLvhA90GpENw1zYQ) Content-type: text/x-vcard; name=David_Zhang.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=David_Zhang.vcf begin:vcard fn:David Zhang n:Zhang;David email;internet:David.Zhang@Sun.COM tel;work:84341 version:2.1 end:vcard --Boundary_(ID_7uqwmOCLvhA90GpENw1zYQ)-- From David.Zhang@sun.com Wed Nov 5 00:34:11 2008 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 mA58YAHj009383 for ; Wed, 5 Nov 2008 00:34:11 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA58Y4U4020341 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 08:34:09 GMT 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 <0K9U00005QGXEY00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 00:34:09 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9U00I9EQGWBN70@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 00:34:08 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA58Y7m6010373 for ; Wed, 05 Nov 2008 08:34:07 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9U00M01PRW3100@fe-emea-09.sun.com> (original mail from David.Zhang@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 08:34:07 +0000 (GMT) Received: from [129.158.148.48] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9U00I46QG3CQ00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 08:33:43 +0000 (GMT) Date: Wed, 05 Nov 2008 16:33:39 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49107661.1040401@sun.com> Sender: David.Zhang@sun.com To: Alan Coopersmith Cc: "Mark A. Carlson" , LSARC-ext@sun.com, Xiao.L@sun.com Message-id: <49115A63.9010706@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_f/Xmw53oSd3QnTlwpy+kbQ)" X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> <49107661.1040401@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 4882 This is a multi-part message in MIME format. --Boundary_(ID_f/Xmw53oSd3QnTlwpy+kbQ) Content-type: multipart/alternative; boundary="Boundary_(ID_cnuRBQwYQkRgOBLCIJ0HqA)" --Boundary_(ID_cnuRBQwYQkRgOBLCIJ0HqA) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Add xiao.l@sun.com into this email loop. On 11/05/08 00:20, Alan Coopersmith wrote: > Mark A. Carlson wrote: > >> I am sponsoring this case for Xiao Li. I have marked it closed approved >> automatic based on the checklist in the case directory. >> > > The answers to this section of the checklist do not agree with the exported > interfaces table, and if answered correctly, would be "ARC review required". > > >> 3.2 Exported Libraries >> Are libraries being delivered by this project? >> [ ] Yes >> [x] No - continue with next section (section 3.3) >> >> Are 64-bit versions of the libraries being delivered? >> [ ] Yes >> [ ] No - ARC review required >> >> Are static versions of the libraries being delivered? >> [ ] Yes - ARC review required >> [ ] No >> > > >>> Exported interface Classification Interface type >>> =============================== ============== ============== >>> /usr/lib/libsgutils.so Private Symbolic link >>> /usr/lib/libsgutils.so.1 Private Symbolic link >>> /usr/lib/libsgutils.so.1.0.0 Private Shared library >>> /usr/lib/libsgutils.a Private Static library >>> /usr/lib/libsgutils.la Private Libtool library >>> file >>> > > If this is indeed a private library, then not having a 64-bit version > is acceptable, but delivering .a & .la files is not. (If no one else > will link with them, why would they be needed? Even if it's public, > delivering .la files is unacceptable as it causes programs built using > libtool to link incorrectly. If it's private, why is it in /usr/lib?) > > --Boundary_(ID_cnuRBQwYQkRgOBLCIJ0HqA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Add xiao.l@sun.com into this email loop.

On 11/05/08 00:20, Alan Coopersmith wrote: 
Mark A. Carlson wrote:
  
I am sponsoring this case for Xiao Li. I have marked it closed approved
automatic based on the checklist in the case directory.
    

The answers to this section of the checklist do not agree with the exported
interfaces table, and if answered correctly, would be "ARC review required".

  
  3.2 Exported Libraries
      Are libraries being delivered by this project?
      [ ] Yes
      [x] No - continue with next section (section 3.3)

      Are 64-bit versions of the libraries being delivered?
      [ ] Yes
      [ ] No - ARC review required
    
      Are static versions of the libraries being delivered?
      [ ] Yes - ARC review required
      [ ] No 
    

  
    Exported interface            Classification    Interface type
    ===============================    ==============    ==============
    /usr/lib/libsgutils.so        Private        Symbolic link
    /usr/lib/libsgutils.so.1        Private        Symbolic link
    /usr/lib/libsgutils.so.1.0.0    Private        Shared library
    /usr/lib/libsgutils.a        Private        Static library
    /usr/lib/libsgutils.la        Private        Libtool library
    file
      

If this is indeed a private library, then not having a 64-bit version
is acceptable, but delivering .a & .la files is not.   (If no one else
will link with them, why would they be needed?   Even if it's public,
delivering .la files is unacceptable as it causes programs built using
libtool to link incorrectly.   If it's private, why is it in /usr/lib?)

--Boundary_(ID_cnuRBQwYQkRgOBLCIJ0HqA)-- --Boundary_(ID_f/Xmw53oSd3QnTlwpy+kbQ) Content-type: text/x-vcard; name=David_Zhang.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=David_Zhang.vcf begin:vcard fn:David Zhang n:Zhang;David email;internet:David.Zhang@Sun.COM tel;work:84341 version:2.1 end:vcard --Boundary_(ID_f/Xmw53oSd3QnTlwpy+kbQ)-- From Xiao.L@sun.com Wed Nov 5 05:01:09 2008 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 mA5D18ZN007276 for ; Wed, 5 Nov 2008 05:01:09 -0800 (PST) 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 mA5D12jj020036 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 21:01:07 +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 <0K9V00F052TSSA00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 05:01:04 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00CFX2TQFN50@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 05:01:03 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5D12wa006853 for ; Wed, 05 Nov 2008 13:01:02 +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 <0K9V00J012QHGL00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 21:01:02 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9V004F52TOU760@mail-apac.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 05 Nov 2008 21:01:01 +0800 (SGT) Date: Wed, 05 Nov 2008 21:03:18 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49115673.6020002@Sun.COM> Sender: Xiao.L@sun.com To: Darren J Moffat Cc: David Zhang , "Mark A. Carlson" , LSARC-ext@sun.com Message-id: <49119996.6000902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> <49105B01.7030204@Sun.COM> <49115673.6020002@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 2029 Please see my comments below. > Add xiao.l@sun.com into this email loop. > > On 11/04/08 22:24, Darren J Moffat wrote: >> Firstly I don't think LSARC is the appropriate ARC body to review a >> case about SCSI utilities I would have expected this to go to PSARC. >> I also don't think that this case qualifies for Self Review given the >> low level nature of the utilities and the possible impact of using them. >> >> How do these commands interact with the existing SCSI tools, >> libraries on Solaris ? Are there any risks to running these >> commands on devices managed by Solaris ? Yes, the commands are sent through the USCSICMD interface, they may either inquiry or modify the information on SCSI devices, so there may be risks I think. >> >> Do all these commands require privilege to run ? If so which >> privileges ? Is there an RBAC profile for them ? I'm not familiar with RBAC, so let me try to answer your questions. These utilities should be run as superuser(root). However for a normal user, he may also be able to run but could fail due to insufficient permission to open the device files. So the required privilege are file_dac_read and file_dac_write, the RBAC profile is "Primary Administrator", am I correct? >> >> Shouldn't they really be in /usr/sbin rather than /usr/bin ? [ Or >> don't we care about that any more ? ] >> Either /usr/sbin/ or /usr/bin is ok to me, I would like know the advice from ARC. >> Is it really appropriate for this case to put header files into the >> already existing /usr/include/scsi/ ? Actually, these header files are only used by sg3 utilities, so it should be ok if we remove these header files. >> >> > /usr/lib/libsgutils.la >> >> I didn't think we normally included libtool libraries, in fact there >> are none currently included in /usr/lib (at least as of snv_100) but >> I did fine some in /usr/sfw/lib/ I just keep it consistent with other platform, like linux. So it's ok if we drop the libtool libraries. -Xiao >> >> -- >> Darren J Moffat > From Xiao.L@sun.com Wed Nov 5 05:06:37 2008 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 mA5D6aBZ007629 for ; Wed, 5 Nov 2008 05:06:36 -0800 (PST) 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 mA5D6Wxi022224 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 21:06:35 +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 <0K9V00G0932XAZ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 05:06:33 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00CEC32VFN60@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 05:06:32 -0800 (PST) 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 mA5D6Vor008013 for ; Wed, 05 Nov 2008 13:06:31 +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 <0K9V00301329AZ00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 21:06:31 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9V00FX632TSBC0@mail-apac.sun.com>; Wed, 05 Nov 2008 21:06:31 +0800 (SGT) Date: Wed, 05 Nov 2008 21:08:47 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49115935.1020401@Sun.COM> Sender: Xiao.L@sun.com To: Alan Coopersmith Cc: David Zhang , Gary Winiger , LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Message-id: <49119ADF.3090701@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cDMr24AKjA63TK9WZRInxg)" X-PMX-Version: 5.4.1.325704 References: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> <491076C2.7000800@sun.com> <49115935.1020401@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 2445 This is a multi-part message in MIME format. --Boundary_(ID_cDMr24AKjA63TK9WZRInxg) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Please see my comments below. David Zhang wrote: > Add xiao.l@sun.com into this email loop. > > On 11/05/08 00:22, Alan Coopersmith wrote: >> Gary Winiger wrote: >> >>>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >>>> >>> Perhaps I missed it, but my recollection was that there was >>> no man8 section. Did it get reintroduced? >>> >> >> Only as bugs by projects which fail to correctly deliver admin man pages >> under the SysV section 1m instead of the BSD section 8. >> >> Sorry I'm confused. Are you suggesting me to put the manpage under /usr/share/man/man1m? >> > --Boundary_(ID_cDMr24AKjA63TK9WZRInxg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Please see my comments below.

David Zhang wrote:
Add xiao.l@sun.com into this email loop.

On 11/05/08 00:22, Alan Coopersmith wrote: 
Gary Winiger wrote:
  
    /usr/share/man/man8/sg_read_long.8	Uncommitted	Manpage
      
	Perhaps I missed it, but my recollection was that there was
	no man8 section.  Did it get reintroduced?
    

Only as bugs by projects which fail to correctly deliver admin man pages
under the SysV section 1m instead of the BSD section 8.
Sorry I'm confused. Are you suggesting me to put the manpage under /usr/share/man/man1m?


--Boundary_(ID_cDMr24AKjA63TK9WZRInxg)-- From Xiao.L@sun.com Wed Nov 5 05:17:34 2008 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 mA5DHXZG008033 for ; Wed, 5 Nov 2008 05:17:33 -0800 (PST) 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 mA5DHU1e026198 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 21:17:32 +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 <0K9V00C033L5AN00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 05:17:29 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V005Q13L4SE80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 05:17:29 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5DHRRu007314 for ; Wed, 05 Nov 2008 13:17:27 +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 <0K9V006013JZXA00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 21:17:27 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9V00F003L2SBD0@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 21:17:27 +0800 (SGT) Date: Wed, 05 Nov 2008 21:19:44 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49115A63.9010706@Sun.COM> Sender: Xiao.L@sun.com To: Alan Coopersmith Cc: David Zhang , "Mark A. Carlson" , LSARC-ext@sun.com Message-id: <49119D70.6040207@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZMpP32gZR5UPqVenSx67Qg)" X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> <49107661.1040401@sun.com> <49115A63.9010706@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 6098 This is a multi-part message in MIME format. --Boundary_(ID_ZMpP32gZR5UPqVenSx67Qg) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Please see my comments below. David Zhang wrote: > Add xiao.l@sun.com into this email loop. > > On 11/05/08 00:20, Alan Coopersmith wrote: >> Mark A. Carlson wrote: >> >>> I am sponsoring this case for Xiao Li. I have marked it closed approved >>> automatic based on the checklist in the case directory. >>> >> >> The answers to this section of the checklist do not agree with the exported >> interfaces table, and if answered correctly, would be "ARC review required". >> >> >>> 3.2 Exported Libraries >>> Are libraries being delivered by this project? >>> [ ] Yes >>> [x] No - continue with next section (section 3.3) >>> >>> Are 64-bit versions of the libraries being delivered? >>> [ ] Yes >>> [ ] No - ARC review required >>> >>> Are static versions of the libraries being delivered? >>> [ ] Yes - ARC review required >>> [ ] No >>> >> >> >>>> Exported interface Classification Interface type >>>> =============================== ============== ============== >>>> /usr/lib/libsgutils.so Private Symbolic link >>>> /usr/lib/libsgutils.so.1 Private Symbolic link >>>> /usr/lib/libsgutils.so.1.0.0 Private Shared library >>>> /usr/lib/libsgutils.a Private Static library >>>> /usr/lib/libsgutils.la Private Libtool library >>>> file >>>> >> >> If this is indeed a private library, then not having a 64-bit version >> is acceptable, but delivering .a & .la files is not. (If no one else >> will link with them, why would they be needed? Even if it's public, >> delivering .la files is unacceptable as it causes programs built using >> libtool to link incorrectly. If it's private, why is it in /usr/lib?) >> >> They are private libraries indeed. It is ok for me to remove the .a and .la files. I just keep them as that on linux. And according to the following link: http://ostest.central.sun.com/wiki/index.php/Package_Delivery_Project (section 3.6) http://sac.eng/cgi-bin/bp.cgi?NAME=install_locations.bp "/usr/sfw" is obsoleted, so I'm putting things under /usr/bin and /usr/lib. However, I would like to know the advice from ARC. Thanks, -Xiao >> > --Boundary_(ID_ZMpP32gZR5UPqVenSx67Qg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT Please see my comments below.

David Zhang wrote:
Add xiao.l@sun.com into this email loop.

On 11/05/08 00:20, Alan Coopersmith wrote: 
Mark A. Carlson wrote:
  
I am sponsoring this case for Xiao Li. I have marked it closed approved
automatic based on the checklist in the case directory.
    

The answers to this section of the checklist do not agree with the exported
interfaces table, and if answered correctly, would be "ARC review required".

  
  3.2 Exported Libraries
      Are libraries being delivered by this project?
      [ ] Yes
      [x] No - continue with next section (section 3.3)

      Are 64-bit versions of the libraries being delivered?
      [ ] Yes
      [ ] No - ARC review required
    
      Are static versions of the libraries being delivered?
      [ ] Yes - ARC review required
      [ ] No 
    

  
    Exported interface            Classification    Interface type
    ===============================    ==============    ==============
    /usr/lib/libsgutils.so        Private        Symbolic link
    /usr/lib/libsgutils.so.1        Private        Symbolic link
    /usr/lib/libsgutils.so.1.0.0    Private        Shared library
    /usr/lib/libsgutils.a        Private        Static library
    /usr/lib/libsgutils.la        Private        Libtool library
    file
      

If this is indeed a private library, then not having a 64-bit version
is acceptable, but delivering .a & .la files is not.   (If no one else
will link with them, why would they be needed?   Even if it's public,
delivering .la files is unacceptable as it causes programs built using
libtool to link incorrectly.   If it's private, why is it in /usr/lib?)
They are private libraries indeed.
It is ok for me to remove the .a and .la files. I just keep them as that on linux.
And according to the following link:
http://ostest.central.sun.com/wiki/index.php/Package_Delivery_Project     (section 3.6)
http://sac.eng/cgi-bin/bp.cgi?NAME=install_locations.bp

"/usr/sfw" is obsoleted, so I'm putting things under /usr/bin and /usr/lib.
However, I would like to know the advice from ARC.
Thanks,
-Xiao

--Boundary_(ID_ZMpP32gZR5UPqVenSx67Qg)-- From David.Zhang@sun.com Wed Nov 5 05:26:59 2008 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 mA5DQx4N008155 for ; Wed, 5 Nov 2008 05:26:59 -0800 (PST) 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 mA5DQwMl062617; Wed, 5 Nov 2008 06:26:59 -0700 (MST) 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 <0K9V00C0D40YOS00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Nov 2008 05:26:58 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V005AN40WRZA0@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Nov 2008 05:26:57 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5DQu2w007571; Wed, 05 Nov 2008 13:26:56 +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 <0K9V005013VCUL00@mail-apac.sun.com> (original mail from David.Zhang@Sun.COM); Wed, 05 Nov 2008 21:26:55 +0800 (SGT) Received: from [129.150.144.39] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9V00IY940T5XG2@mail-apac.sun.com>; Wed, 05 Nov 2008 21:26:55 +0800 (SGT) Date: Wed, 05 Nov 2008 21:26:55 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49104FD7.9070206@Sun.COM> Sender: David.Zhang@sun.com To: James.McPherson@sun.com Cc: Mark Carlson , LSARC-ext@sun.com, Xiao.L@sun.com, spsg-gz@sun.com Message-id: <49119F1F.8060902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104FD7.9070206@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 11386 Add xiao.l@sun.com into this email loop. > Mark Carlson wrote: >> Template Version: @(#)sac_nextcase %I% %G% SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Sg3 utilities 1.25 >> 1.2. Name of Document Author/Supplier: >> Author: Xiao Li >> 1.3 Date of This Document: >> 04 November, 2008 >> >> 2. Project Summary >> 2.1. Project Description >> >> This project introduces the package of Sg3 utilites 1.25 into >> the SFW consolidation. >> 4. Technical Description >> >> The sg3_utils package contains utilities that send SCSI commands to >> devices. As well as devices on transports traditionally associated >> with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and >> the SCSI Parallel Interface(SPI)) and many other devices use SCSI >> command sets. ATAPI cd/dvd drives and SATA disks that connect via a >> translation layer or a bridge device are examples of devices that >> use SCSI command sets. > > Are these utilities going to make use of the existing features > in OpenSolaris which make writing such utilities *really easy*? > > ie, using libscsi and libses, as well as ? > > Or will they be an as-close-as-possible port from other parts > of the OpenSource ecosystem? > > James > > > >> There are about 32 command line utilities inside this package. >> Command name Notes >> ============ =================================================== >> sg_get_config fetch features and profiles of a cd/dvd drive >> and/or >> its current media >> sg_ident default is to report (fetch) the device identifier. >> With the '--set' option a new identifier is sent to >> the device. >> sg_inq fetch standard response, VPD pages or version >> descriptors. Also can perform IDENTIFY (PACKET) >> DEVICE ATA command. VPD page decoding also performed >> by sg_vpd and sdparm. >> sg_logs fetch log sense pages, decode standard and some >> vendor >> pages >> sg_luns fetch luns reported by a device (lun 0 or "well known >> lu") >> sg_modes fetch mode pages (output mainly in hex, to decode >> output use sdparm) >> sg_opcodes fetch supported SCSI commands or supported task >> management functions >> sg_persist control persistent reservations and report reservation >> status >> sg_prevent control media removal, mainly for those SCSI devices >> which have removable media (e.g. CD/DVD and tape drives) >> sg_raw send user supplied cdb >> sg_rdac display or modify RDAC redundant controller mode page >> sg_read_buffer read descriptors or data >> sg_read_long read data from given lba which includes the block >> and >> ECC data. >> sg_readcap fetch the number of blocks and the individual block >> size for disks and CD/DVD media >> sg_reassign reassign a lba from one sector on a disk (typically >> damaged) to a new (spare) sector. User data copied if >> it is recoverable. >> sg_requests fetch sense data from the given device. Modern uses >> include getting a progress indication (e.g. during a >> format) or finding the power condition state. >> sg_rmsn Relatively new command added to SPC-3. Format of >> response is vendor specific so this utility outputs >> it in hex (default) or binary. >> sg_rtpg Specialized for multi-ported SCSI devices where one >> port (or a group of them) is preferred for IO over >> another (or others). >> sg_safte fetch information from a SAF-TE processor. >> sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET >> DEVICE >> commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI >> command. >> sg_sat_set_features Sends ATA SET FEATURES command via SAT. >> sg_senddiag Issues either a default self test or a short/extended >> foreground/background self test. With no arguments it >> uses RECEIVE DIAGNOSTIC RESULTS to list all supported >> diagnostic pages. >> sg_ses Fetches status diagnostic pages from, and sends some >> control pages to, a SCSI Enclosure Services (SES) >> device. >> sg_start Controls the power condition state of a SCSI device. >> Primary use is to spin up and down SCSI disks. Can >> also load and eject removable media. >> sg_stpg Specialized for multi-ported SCSI devices where one >> port (or a group of them) is preferred for IO over >> another (or others). >> sg_sync Causes disk caches to be flushed to media. >> sg_turs Issue one or more Test Unit Ready commands. Can be >> used to time SCSI command overhead. >> sg_verify reads indicated blocks on a SCSI disks, stops on the >> first error found. Does not yield any data. Useful >> for media scans. >> sg_vpd Decodes standard and some vendor Vital Product Data >> (VPD) pages. >> sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from >> "sg_modes -r") to the SCSI device. See sdparm for >> another method of setting mode page parameters. >> sg_write_buffer write data; can be used to download firmware. >> sg_write_long writes to a lba, data which includes the block and >> ECC data. Suitable data typically fetched by prior >> sg_read_long utility. >> 5. Interfaces >> >> Exported interface Classification Interface type >> =============================== ============== ============== >> SUNWsg3utils Uncommitted Package name >> /usr/bin/sg_get_config Uncommitted Command >> /usr/bin/sg_ident Uncommitted Command >> /usr/bin/sg_inq Uncommitted Command >> /usr/bin/sg_logs Uncommitted Command >> /usr/bin/sg_luns Uncommitted Command >> /usr/bin/sg_modes Uncommitted Command >> /usr/bin/sg_opcodes Uncommitted Command >> /usr/bin/sg_persist Uncommitted Command >> /usr/bin/sg_prevent Uncommitted Command >> /usr/bin/sg_raw Uncommitted Command >> /usr/bin/sg_rdac Uncommitted Command >> /usr/bin/sg_read_buffer Uncommitted Command >> /usr/bin/sg_read_long Uncommitted Command >> /usr/bin/sg_readcap Uncommitted Command >> /usr/bin/sg_reassign Uncommitted Command >> /usr/bin/sg_requests Uncommitted Command >> /usr/bin/sg_rmsn Uncommitted Command >> /usr/bin/sg_rtpg Uncommitted Command >> /usr/bin/sg_safte Uncommitted Command >> /usr/bin/sg_sat_identify Uncommitted Command >> /usr/bin/sg_sat_set_features Uncommitted Command >> /usr/bin/sg_senddiag Uncommitted Command >> /usr/bin/sg_ses Uncommitted Command >> /usr/bin/sg_start Uncommitted Command >> /usr/bin/sg_stpg Uncommitted Command >> /usr/bin/sg_sync Uncommitted Command >> /usr/bin/sg_turs Uncommitted Command >> /usr/bin/sg_verify Uncommitted Command >> /usr/bin/sg_vpd Uncommitted Command >> /usr/bin/sg_wr_mode Uncommitted Command >> /usr/bin/sg_write_buffer Uncommitted Command >> /usr/bin/sg_write_long Uncommitted Command >> /usr/lib/libsgutils.so Private Symbolic link >> /usr/lib/libsgutils.so.1 Private Symbolic link >> /usr/lib/libsgutils.so.1.0.0 Private Shared library >> /usr/lib/libsgutils.a Private Static library >> /usr/lib/libsgutils.la Private Libtool library >> file >> /usr/include/scsi/sg_lib.h Uncommitted Header file >> /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file >> /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file >> /usr/include/scsi/sg_cmds.h Uncommitted Header file >> /usr/include/scsi/sg_pt.h Uncommitted Header file >> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >> /usr/share/man/man8/sg_safte.8 Uncommitted Manpage >> /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage >> /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage >> /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage >> /usr/share/man/man8/sg_persist.8 Uncommitted Manpage >> /usr/share/man/man8/sg_ses.8 Uncommitted Manpage >> /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage >> /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage >> /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage >> /usr/share/man/man8/sg_luns.8 Uncommitted Manpage >> /usr/share/man/man8/sg_requests.8 Uncommitted Manpage >> /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage >> /usr/share/man/man8/sg_start.8 Uncommitted Manpage >> /usr/share/man/man8/sg_verify.8 Uncommitted Manpage >> /usr/share/man/man8/sg_modes.8 Uncommitted Manpage >> /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage >> /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage >> /usr/share/man/man8/sg_ident.8 Uncommitted Manpage >> /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage >> /usr/share/man/man8/sg_inq.8 Uncommitted Manpage >> /usr/share/man/man8/sg_raw.8 Uncommitted Manpage >> /usr/share/man/man8/sg_turs.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sync.8 Uncommitted Manpage >> /usr/share/man/man8/sg_logs.8 Uncommitted Manpage >> /usr/share/man/man8/sg_format.8 Uncommitted Manpage >> /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage >> /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage >> /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage >> >> The following additional installed files are not interface. >> >> Additional document >> ------------------- >> N/A >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: Automatic >> 6.6. ARC Exposure: open >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > > From Xiao.L@Sun.COM Wed Nov 5 06:13:42 2008 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 mA5EDgZE009963 for ; Wed, 5 Nov 2008 06:13:42 -0800 (PST) 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 mA5EDeTs022112; Wed, 5 Nov 2008 06:13:42 -0800 (PST) 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 <0K9V00H1B66UD000@brm-avmta-1.central.sun.com>; Wed, 05 Nov 2008 07:13:42 -0700 (MST) 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 <0K9V00CPI66SFM40@brm-avmta-1.central.sun.com>; Wed, 05 Nov 2008 07:13:41 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5EDeg7009653; Wed, 05 Nov 2008 14:13:40 +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 <0K9V0000161AVT00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) ; Wed, 05 Nov 2008 22:13:40 +0800 (SGT) Received: from [192.168.0.137] ([123.112.20.52]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9V00IVC66F5XP2@mail-apac.sun.com>; Wed, 05 Nov 2008 22:13:40 +0800 (SGT) Date: Wed, 05 Nov 2008 22:13:44 +0800 From: Xiao Li Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49119F1F.8060902@Sun.COM> Sender: Xiao.L@Sun.COM To: James.McPherson@Sun.COM Cc: David Zhang , Mark Carlson , LSARC-ext@Sun.COM, spsg-gz@Sun.COM Message-id: <4911AA18.80400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104FD7.9070206@Sun.COM> <49119F1F.8060902@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 11809 Please see my comments below. David Zhang wrote: > Add xiao.l@sun.com into this email loop. >> Mark Carlson wrote: >>> Template Version: @(#)sac_nextcase %I% %G% SMI >>> This information is Copyright 2008 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Sg3 utilities 1.25 >>> 1.2. Name of Document Author/Supplier: >>> Author: Xiao Li >>> 1.3 Date of This Document: >>> 04 November, 2008 >>> >>> 2. Project Summary >>> 2.1. Project Description >>> >>> This project introduces the package of Sg3 utilites 1.25 >>> into the SFW consolidation. >>> 4. Technical Description >>> >>> The sg3_utils package contains utilities that send SCSI commands to >>> devices. As well as devices on transports traditionally associated >>> with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and >>> the SCSI Parallel Interface(SPI)) and many other devices use SCSI >>> command sets. ATAPI cd/dvd drives and SATA disks that connect via a >>> translation layer or a bridge device are examples of devices that >>> use SCSI command sets. >> >> Are these utilities going to make use of the existing features >> in OpenSolaris which make writing such utilities *really easy*? >> >> ie, using libscsi and libses, as well as ? No, it is not using these libraries. >> >> Or will they be an as-close-as-possible port from other parts >> of the OpenSource ecosystem? Our strategy is to keep it as-close-as-possible to avoid forking from upstream. Thanks, -Xiao >> >> James >> >> >> >>> There are about 32 command line utilities inside this package. >>> Command name Notes >>> ============ =================================================== >>> sg_get_config fetch features and profiles of a cd/dvd drive >>> and/or >>> its current media >>> sg_ident default is to report (fetch) the device identifier. >>> With the '--set' option a new identifier is sent to >>> the device. >>> sg_inq fetch standard response, VPD pages or version >>> descriptors. Also can perform IDENTIFY (PACKET) >>> DEVICE ATA command. VPD page decoding also performed >>> by sg_vpd and sdparm. >>> sg_logs fetch log sense pages, decode standard and some >>> vendor >>> pages >>> sg_luns fetch luns reported by a device (lun 0 or "well >>> known >>> lu") >>> sg_modes fetch mode pages (output mainly in hex, to decode >>> output use sdparm) >>> sg_opcodes fetch supported SCSI commands or supported task >>> management functions >>> sg_persist control persistent reservations and report >>> reservation >>> status >>> sg_prevent control media removal, mainly for those SCSI devices >>> which have removable media (e.g. CD/DVD and tape drives) >>> sg_raw send user supplied cdb >>> sg_rdac display or modify RDAC redundant controller mode >>> page >>> sg_read_buffer read descriptors or data >>> sg_read_long read data from given lba which includes the >>> block and >>> ECC data. >>> sg_readcap fetch the number of blocks and the individual block >>> size for disks and CD/DVD media >>> sg_reassign reassign a lba from one sector on a disk (typically >>> damaged) to a new (spare) sector. User data copied if >>> it is recoverable. >>> sg_requests fetch sense data from the given device. Modern uses >>> include getting a progress indication (e.g. during a >>> format) or finding the power condition state. >>> sg_rmsn Relatively new command added to SPC-3. Format of >>> response is vendor specific so this utility outputs >>> it in hex (default) or binary. >>> sg_rtpg Specialized for multi-ported SCSI devices where one >>> port (or a group of them) is preferred for IO over >>> another (or others). >>> sg_safte fetch information from a SAF-TE processor. >>> sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET >>> DEVICE >>> commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI >>> command. >>> sg_sat_set_features Sends ATA SET FEATURES command via SAT. >>> sg_senddiag Issues either a default self test or a >>> short/extended >>> foreground/background self test. With no arguments it >>> uses RECEIVE DIAGNOSTIC RESULTS to list all supported >>> diagnostic pages. >>> sg_ses Fetches status diagnostic pages from, and sends some >>> control pages to, a SCSI Enclosure Services (SES) >>> device. >>> sg_start Controls the power condition state of a SCSI device. >>> Primary use is to spin up and down SCSI disks. Can >>> also load and eject removable media. >>> sg_stpg Specialized for multi-ported SCSI devices where one >>> port (or a group of them) is preferred for IO over >>> another (or others). >>> sg_sync Causes disk caches to be flushed to media. >>> sg_turs Issue one or more Test Unit Ready commands. Can be >>> used to time SCSI command overhead. >>> sg_verify reads indicated blocks on a SCSI disks, stops on the >>> first error found. Does not yield any data. Useful >>> for media scans. >>> sg_vpd Decodes standard and some vendor Vital Product Data >>> (VPD) pages. >>> sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from >>> "sg_modes -r") to the SCSI device. See sdparm for >>> another method of setting mode page parameters. >>> sg_write_buffer write data; can be used to download firmware. >>> sg_write_long writes to a lba, data which includes the block and >>> ECC data. Suitable data typically fetched by prior >>> sg_read_long utility. >>> 5. Interfaces >>> >>> Exported interface Classification Interface type >>> =============================== ============== ============== >>> SUNWsg3utils Uncommitted Package name >>> /usr/bin/sg_get_config Uncommitted Command >>> /usr/bin/sg_ident Uncommitted Command >>> /usr/bin/sg_inq Uncommitted Command >>> /usr/bin/sg_logs Uncommitted Command >>> /usr/bin/sg_luns Uncommitted Command >>> /usr/bin/sg_modes Uncommitted Command >>> /usr/bin/sg_opcodes Uncommitted Command >>> /usr/bin/sg_persist Uncommitted Command >>> /usr/bin/sg_prevent Uncommitted Command >>> /usr/bin/sg_raw Uncommitted Command >>> /usr/bin/sg_rdac Uncommitted Command >>> /usr/bin/sg_read_buffer Uncommitted Command >>> /usr/bin/sg_read_long Uncommitted Command >>> /usr/bin/sg_readcap Uncommitted Command >>> /usr/bin/sg_reassign Uncommitted Command >>> /usr/bin/sg_requests Uncommitted Command >>> /usr/bin/sg_rmsn Uncommitted Command >>> /usr/bin/sg_rtpg Uncommitted Command >>> /usr/bin/sg_safte Uncommitted Command >>> /usr/bin/sg_sat_identify Uncommitted Command >>> /usr/bin/sg_sat_set_features Uncommitted Command >>> /usr/bin/sg_senddiag Uncommitted Command >>> /usr/bin/sg_ses Uncommitted Command >>> /usr/bin/sg_start Uncommitted Command >>> /usr/bin/sg_stpg Uncommitted Command >>> /usr/bin/sg_sync Uncommitted Command >>> /usr/bin/sg_turs Uncommitted Command >>> /usr/bin/sg_verify Uncommitted Command >>> /usr/bin/sg_vpd Uncommitted Command >>> /usr/bin/sg_wr_mode Uncommitted Command >>> /usr/bin/sg_write_buffer Uncommitted Command >>> /usr/bin/sg_write_long Uncommitted Command >>> /usr/lib/libsgutils.so Private Symbolic link >>> /usr/lib/libsgutils.so.1 Private Symbolic link >>> /usr/lib/libsgutils.so.1.0.0 Private Shared library >>> /usr/lib/libsgutils.a Private Static library >>> /usr/lib/libsgutils.la Private Libtool library >>> file >>> /usr/include/scsi/sg_lib.h Uncommitted Header file >>> /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file >>> /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file >>> /usr/include/scsi/sg_cmds.h Uncommitted Header file >>> /usr/include/scsi/sg_pt.h Uncommitted Header file >>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_safte.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_persist.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_ses.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_luns.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_requests.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_start.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_verify.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_modes.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage >>> /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_ident.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_inq.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_raw.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_turs.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_sync.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_logs.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_format.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage >>> /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage >>> >>> The following additional installed files are not interface. >>> >>> Additional document >>> ------------------- >>> N/A >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> SFW >>> 6.5. ARC review type: Automatic >>> 6.6. ARC Exposure: open >>> >>> _______________________________________________ >>> opensolaris-arc mailing list >>> opensolaris-arc@opensolaris.org >> >> > From Alan.Coopersmith@sun.com Wed Nov 5 07:16:18 2008 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 mA5FGIXp011683 for ; Wed, 5 Nov 2008 07:16:18 -0800 (PST) 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 mA5FGDQ3046131 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 08:16:17 -0700 (MST) 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 <0K9V0065L9340400@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 07:16:16 -0800 (PST) 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 <0K9V00MC9934TA70@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 07:16:16 -0800 (PST) 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 mA5FGGhm016657 for ; Wed, 05 Nov 2008 07:16:16 -0800 (PST) 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 <0K9V0050185C7700@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 07:16:16 -0800 (PST) Received: from [10.6.102.118] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9V006BE932Q210@fe-sfbay-09.sun.com>; Wed, 05 Nov 2008 07:16:15 -0800 (PST) Date: Wed, 05 Nov 2008 07:16:14 -0800 From: Alan Coopersmith Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49119ADF.3090701@sun.com> Sender: Alan.Coopersmith@sun.com To: xiao li - Sun Microsystems - Beijing China Cc: David Zhang , Gary Winiger , LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Message-id: <4911B8BE.7010008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200811041601.mA4G1YE2007967@marduk.eng.sun.com> <491076C2.7000800@sun.com> <49115935.1020401@Sun.COM> <49119ADF.3090701@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 935 xiao li - Sun Microsystems - Beijing China wrote: > Please see my comments below. > > David Zhang wrote: >> Add xiao.l@sun.com into this email loop. >> >> On 11/05/08 00:22, Alan Coopersmith wrote: >>> Gary Winiger wrote: >>> >>>>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >>>>> >>>> Perhaps I missed it, but my recollection was that there was >>>> no man8 section. Did it get reintroduced? >>>> >>> >>> Only as bugs by projects which fail to correctly deliver admin man pages >>> under the SysV section 1m instead of the BSD section 8. >>> >>> > Sorry I'm confused. Are you suggesting me to put the manpage under > /usr/share/man/man1m? Yes - man pages which BSD-style systems (including Linux) put under man8 are installed under man1m on Solaris & other SysV-style systems. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From carlsonj@phorcys.east.sun.com Wed Nov 5 07:17:04 2008 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 mA5FH4sP011705 for ; Wed, 5 Nov 2008 07:17:04 -0800 (PST) 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 mA5FGsve046483; Wed, 5 Nov 2008 08:17:00 -0700 (MST) 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 <0K9V00G0J94BLS00@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Nov 2008 07:16:59 -0800 (PST) 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 <0K9V00GVW94A3X10@nwk-avmta-2.sfbay.sun.com>; Wed, 05 Nov 2008 07:16:58 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mA5FGvSQ011426; Wed, 05 Nov 2008 10:16:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mA5FGvbx011423; Wed, 05 Nov 2008 10:16:57 -0500 (EST) Date: Wed, 05 Nov 2008 10:16:57 -0500 From: James Carlson Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <49119996.6000902@sun.com> To: xiao li - Sun Microsystems - Beijing China Cc: Darren J Moffat , "Mark A. Carlson" , LSARC-ext@sun.com, David Zhang Message-id: <18705.47337.831832.800601@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.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> <49104F05.7070305@sun.com> <49105B01.7030204@Sun.COM> <49115673.6020002@Sun.COM> <49119996.6000902@sun.com> Status: RO Content-Length: 641 xiao li - Sun Microsystems - Beijing China writes: > >> Shouldn't they really be in /usr/sbin rather than /usr/bin ? [ Or > >> don't we care about that any more ? ] > >> > Either /usr/sbin/ or /usr/bin is ok to me, I would like know the advice > from ARC. If they're things intended for an administrator, then /usr/sbin is the right place. /usr/bin is intended for ordinary users. See filesystem(5) for details. -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Wed Nov 5 07:48:08 2008 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 mA5Fm8gx012124 for ; Wed, 5 Nov 2008 07:48:08 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA5Fm8Rf001847 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 07:48:08 -0800 (PST) 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 <0K9V00H1JAK7XK00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 07:48:07 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00GDCAK53Y60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 07:48:06 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA5Fm3BH033449; Wed, 05 Nov 2008 07:48:03 -0800 (PST) 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 mA5Fm8Ux009111; Wed, 05 Nov 2008 07:48:08 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA5Fm8vN009110; Wed, 05 Nov 2008 07:48:08 -0800 (PST) Date: Wed, 05 Nov 2008 07:48:08 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] To: Xiao.L@sun.com, Alan.Coopersmith@sun.com Cc: David.Zhang@sun.com, gww@eng.sun.com, LSARC-ext@sun.com, markcarl@sac.sfbay.sun.com Message-id: <200811051548.mA5Fm8vN009110@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1118 > >> On 11/05/08 00:22, Alan Coopersmith wrote: > >>> Gary Winiger wrote: > >>> > >>>>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage > >>>>> > >>>> Perhaps I missed it, but my recollection was that there was > >>>> no man8 section. Did it get reintroduced? > >>>> > >>> > >>> Only as bugs by projects which fail to correctly deliver admin man pages > >>> under the SysV section 1m instead of the BSD section 8. > >>> > >>> > > Sorry I'm confused. Are you suggesting me to put the manpage under > > /usr/share/man/man1m? > > Yes - man pages which BSD-style systems (including Linux) put under man8 > are installed under man1m on Solaris & other SysV-style systems. Unless they've been overridden, there is adequate case precedent for the project team to follow. In specific see: PSARC/1999/555 Getting with the Freeware Program PSARC/2000/488 Solaris/Linux Commands Compatibility PSARC/2005/185 Enabling serendipitous discovery PSARC/2005/220 New Public Taxonomy PSARC/2007/048 Include GNU coreutils 6.7 Your case owner should point you to the relevant precedent. Gary.. From Mark.Carlson@sun.com Wed Nov 5 10:07:48 2008 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 mA5I7maI019804 for ; Wed, 5 Nov 2008 10:07:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA5I7kdR006676 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 5 Nov 2008 10:07:48 -0800 (PST) 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 <0K9V00M17H0ZCE00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 10:07:47 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00KXQH0Y3R50@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 10:07:47 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5I7kMn020901 for ; Wed, 05 Nov 2008 18:07:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9V00J01FZE3Y00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 11:07:46 -0700 (MST) Received: from Macintosh-252.local ([129.150.65.235]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9V000S6H0QUM50@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 05 Nov 2008 11:07:39 -0700 (MST) Date: Wed, 05 Nov 2008 11:07:38 -0700 From: "Mark A. Carlson" Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <200811051548.mA5Fm8vN009110@marduk.eng.sun.com> Sender: Mark.Carlson@sun.com To: LSARC-ext@sun.com Cc: Xiao.L@sun.com, David.Zhang@sun.com Message-id: <4911E0EA.8030503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811051548.mA5Fm8vN009110@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 105 This case has been moved to PSARC, please direct email conversation to PSARC-ext going forward. -- mark From Mark.Carlson@sun.com Wed Nov 5 10:08:05 2008 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 mA5I84ap019845 for ; Wed, 5 Nov 2008 10:08:05 -0800 (PST) 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 mA5I7wR3009969 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Nov 2008 02:08:03 +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 <0K9V0093PH1CYQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:08:00 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V008QPH18Q420@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:07:56 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA5I7uAl020993 for ; Wed, 05 Nov 2008 18:07:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9V00M01GGM2B00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:07:56 -0700 (MST) Received: from Macintosh-252.local ([129.150.65.235]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9V00EXVH16DM40@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:07:55 -0700 (MST) Date: Wed, 05 Nov 2008 11:07:54 -0700 From: "Mark A. Carlson" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811051548.mA5Fm8vN009110@marduk.eng.sun.com> Sender: Mark.Carlson@sun.com To: PSARC-ext@sun.com Cc: Xiao.L@sun.com, David.Zhang@sun.com Message-id: <4911E0FA.9010306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811051548.mA5Fm8vN009110@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 155 This case - Sg3 utilities 1.25 - has been moved here to PSARC from LSARC. Please direct email conversations to this list going forward. Thanks, -- mark From gww@eng.sun.com Wed Nov 5 11:10:38 2008 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 mA5JAcPK022217 for ; Wed, 5 Nov 2008 11:10:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA5JAaju016094 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Nov 2008 11:10:37 -0800 (PST) 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 <0K9V0010NJXPOI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:10:37 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00K3CJXO3FD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 11:10:37 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA5JAY00050142; Wed, 05 Nov 2008 11:10:34 -0800 (PST) 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 mA5JAd7e009563; Wed, 05 Nov 2008 11:10:39 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA5JAdOU009562; Wed, 05 Nov 2008 11:10:39 -0800 (PST) Date: Wed, 05 Nov 2008 11:10:39 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] To: PSARC-ext@sun.com, Mark.Carlson@sun.com Cc: Xiao.L@sun.com, David.Zhang@sun.com Message-id: <200811051910.mA5JAdOU009562@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 630 > This case - Sg3 utilities 1.25 - has been moved here to PSARC from LSARC. > > Please direct email conversations to this list going forward. And do you believe it still stands as self review? There seem to be actual questions that are architectural not answered in the spec. Viz: >From Darren.Moffat@Sun.COM Tue Nov 4 06:24:18 2008 How do these commands interact with the existing SCSI tools, libraries on Solaris ? Are there any risks to running these commands on devices managed by Solaris ? Do all these commands require privilege to run ? If so which privileges ? Is there an RBAC profile for them ? Gary.. From gww@eng.sun.com Wed Nov 5 14:48:57 2008 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 mA5MmuU6028647 for ; Wed, 5 Nov 2008 14:48:56 -0800 (PST) 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 mA5Mmql7013153 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Nov 2008 06:48: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 <0K9V00A0TU1HF400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 14:48:53 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V003S6U1GE4D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 14:48:52 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA5Mmnne065278; Wed, 05 Nov 2008 14:48:49 -0800 (PST) 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 mA5MmtE7009729; Wed, 05 Nov 2008 14:48:55 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA5MmsEO009728; Wed, 05 Nov 2008 14:48:54 -0800 (PST) Date: Wed, 05 Nov 2008 14:48:54 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 FastTrack timeout 11/12/2008] To: Mark.Carlson@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Cc: David.Zhang@sun.com, Xiao.L@sun.com Message-id: <200811052248.mA5MmsEO009728@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 9166 > > Please direct email conversations to this list going forward. > > And do you believe it still stands as self review? At the request of the case owner, I've changed this to a fast track and set the timer for 12 Nov. A reply of the spec is below. Gary.. ====== This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Sg3 utilities 1.25 1.2. Name of Document Author/Supplier: Author: Xiao Li 1.3 Date of This Document: 04 November, 2008 2. Project Summary 2.1. Project Description This project introduces the package of Sg3 utilites 1.25 into the SFW consolidation. 4. Technical Description The sg3_utils package contains utilities that send SCSI commands to devices. As well as devices on transports traditionally associated with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and the SCSI Parallel Interface(SPI)) and many other devices use SCSI command sets. ATAPI cd/dvd drives and SATA disks that connect via a translation layer or a bridge device are examples of devices that use SCSI command sets. There are about 32 command line utilities inside this package. Command name Notes ============ =================================================== sg_get_config fetch features and profiles of a cd/dvd drive and/or its current media sg_ident default is to report (fetch) the device identifier. With the '--set' option a new identifier is sent to the device. sg_inq fetch standard response, VPD pages or version descriptors. Also can perform IDENTIFY (PACKET) DEVICE ATA command. VPD page decoding also performed by sg_vpd and sdparm. sg_logs fetch log sense pages, decode standard and some vendor pages sg_luns fetch luns reported by a device (lun 0 or "well known lu") sg_modes fetch mode pages (output mainly in hex, to decode output use sdparm) sg_opcodes fetch supported SCSI commands or supported task management functions sg_persist control persistent reservations and report reservation status sg_prevent control media removal, mainly for those SCSI devices which have removable media (e.g. CD/DVD and tape drives) sg_raw send user supplied cdb sg_rdac display or modify RDAC redundant controller mode page sg_read_buffer read descriptors or data sg_read_long read data from given lba which includes the block and ECC data. sg_readcap fetch the number of blocks and the individual block size for disks and CD/DVD media sg_reassign reassign a lba from one sector on a disk (typically damaged) to a new (spare) sector. User data copied if it is recoverable. sg_requests fetch sense data from the given device. Modern uses include getting a progress indication (e.g. during a format) or finding the power condition state. sg_rmsn Relatively new command added to SPC-3. Format of response is vendor specific so this utility outputs it in hex (default) or binary. sg_rtpg Specialized for multi-ported SCSI devices where one port (or a group of them) is preferred for IO over another (or others). sg_safte fetch information from a SAF-TE processor. sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI command. sg_sat_set_features Sends ATA SET FEATURES command via SAT. sg_senddiag Issues either a default self test or a short/extended foreground/background self test. With no arguments it uses RECEIVE DIAGNOSTIC RESULTS to list all supported diagnostic pages. sg_ses Fetches status diagnostic pages from, and sends some control pages to, a SCSI Enclosure Services (SES) device. sg_start Controls the power condition state of a SCSI device. Primary use is to spin up and down SCSI disks. Can also load and eject removable media. sg_stpg Specialized for multi-ported SCSI devices where one port (or a group of them) is preferred for IO over another (or others). sg_sync Causes disk caches to be flushed to media. sg_turs Issue one or more Test Unit Ready commands. Can be used to time SCSI command overhead. sg_verify reads indicated blocks on a SCSI disks, stops on the first error found. Does not yield any data. Useful for media scans. sg_vpd Decodes standard and some vendor Vital Product Data (VPD) pages. sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from "sg_modes -r") to the SCSI device. See sdparm for another method of setting mode page parameters. sg_write_buffer write data; can be used to download firmware. sg_write_long writes to a lba, data which includes the block and ECC data. Suitable data typically fetched by prior sg_read_long utility. 5. Interfaces Exported interface Classification Interface type =============================== ============== ============== SUNWsg3utils Uncommitted Package name /usr/bin/sg_get_config Uncommitted Command /usr/bin/sg_ident Uncommitted Command /usr/bin/sg_inq Uncommitted Command /usr/bin/sg_logs Uncommitted Command /usr/bin/sg_luns Uncommitted Command /usr/bin/sg_modes Uncommitted Command /usr/bin/sg_opcodes Uncommitted Command /usr/bin/sg_persist Uncommitted Command /usr/bin/sg_prevent Uncommitted Command /usr/bin/sg_raw Uncommitted Command /usr/bin/sg_rdac Uncommitted Command /usr/bin/sg_read_buffer Uncommitted Command /usr/bin/sg_read_long Uncommitted Command /usr/bin/sg_readcap Uncommitted Command /usr/bin/sg_reassign Uncommitted Command /usr/bin/sg_requests Uncommitted Command /usr/bin/sg_rmsn Uncommitted Command /usr/bin/sg_rtpg Uncommitted Command /usr/bin/sg_safte Uncommitted Command /usr/bin/sg_sat_identify Uncommitted Command /usr/bin/sg_sat_set_features Uncommitted Command /usr/bin/sg_senddiag Uncommitted Command /usr/bin/sg_ses Uncommitted Command /usr/bin/sg_start Uncommitted Command /usr/bin/sg_stpg Uncommitted Command /usr/bin/sg_sync Uncommitted Command /usr/bin/sg_turs Uncommitted Command /usr/bin/sg_verify Uncommitted Command /usr/bin/sg_vpd Uncommitted Command /usr/bin/sg_wr_mode Uncommitted Command /usr/bin/sg_write_buffer Uncommitted Command /usr/bin/sg_write_long Uncommitted Command /usr/lib/libsgutils.so Private Symbolic link /usr/lib/libsgutils.so.1 Private Symbolic link /usr/lib/libsgutils.so.1.0.0 Private Shared library /usr/lib/libsgutils.a Private Static library /usr/lib/libsgutils.la Private Libtool library file /usr/include/scsi/sg_lib.h Uncommitted Header file /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file /usr/include/scsi/sg_cmds.h Uncommitted Header file /usr/include/scsi/sg_pt.h Uncommitted Header file /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage /usr/share/man/man8/sg_safte.8 Uncommitted Manpage /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage /usr/share/man/man8/sg_persist.8 Uncommitted Manpage /usr/share/man/man8/sg_ses.8 Uncommitted Manpage /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage /usr/share/man/man8/sg_luns.8 Uncommitted Manpage /usr/share/man/man8/sg_requests.8 Uncommitted Manpage /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage /usr/share/man/man8/sg_start.8 Uncommitted Manpage /usr/share/man/man8/sg_verify.8 Uncommitted Manpage /usr/share/man/man8/sg_modes.8 Uncommitted Manpage /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage /usr/share/man/man8/sg_ident.8 Uncommitted Manpage /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage /usr/share/man/man8/sg_inq.8 Uncommitted Manpage /usr/share/man/man8/sg_raw.8 Uncommitted Manpage /usr/share/man/man8/sg_turs.8 Uncommitted Manpage /usr/share/man/man8/sg_sync.8 Uncommitted Manpage /usr/share/man/man8/sg_logs.8 Uncommitted Manpage /usr/share/man/man8/sg_format.8 Uncommitted Manpage /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage The following additional installed files are not interface. Additional document ------------------- N/A 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From gww@eng.sun.com Wed Nov 5 15:01:26 2008 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 mA5N1PSs029195 for ; Wed, 5 Nov 2008 15:01:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA5N1IXM015830 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Nov 2008 23:01:24 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9V0060DUMBFC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 15:01:23 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9V00L71UMAFRD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 15:01:22 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA5N1Jjf007846; Wed, 05 Nov 2008 15:01:19 -0800 (PST) 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 mA5N1OQR009754; Wed, 05 Nov 2008 15:01:25 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA5N1OZr009753; Wed, 05 Nov 2008 15:01:24 -0800 (PST) Date: Wed, 05 Nov 2008 15:01:24 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 FastTrack timeout 11/12/2008] To: Mark.Carlson@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Cc: David.Zhang@sun.com, Xiao.L@sun.com Message-id: <200811052301.mA5N1OZr009753@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 317 No matter how many times I proof things..... > At the request of the case owner, I've changed this to > a fast track and set the timer for 12 Nov. > A reply of the spec is below. ^^^^^ replay Perhaps not clear from Mark's original mail is that there has already been the start of a discussion. Gary.. From Xiao.L@sun.com Wed Nov 5 17:42:05 2008 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 mA61g5wm002431 for ; Wed, 5 Nov 2008 17:42:05 -0800 (PST) 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 mA61g24e006035 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Nov 2008 18:42:04 -0700 (MST) 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 <0K9W00J0L223XU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 18:42:03 -0700 (MST) 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 <0K9W002C12207AE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 18:42:01 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA61g0OP025501 for ; Thu, 06 Nov 2008 01:42:00 +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 <0K9W007011W2M100@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 09:42:00 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9W004T321YU780@mail-apac.sun.com>; Thu, 06 Nov 2008 09:41:59 +0800 (SGT) Date: Thu, 06 Nov 2008 09:44:16 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811051910.mA5JAdOU009562@marduk.eng.sun.com> Sender: Xiao.L@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Mark.Carlson@sun.com, David.Zhang@sun.com Message-id: <49124BF0.4060306@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6xatc77rW6rqQlG6ltLVQA)" X-PMX-Version: 5.4.1.325704 References: <200811051910.mA5JAdOU009562@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 3584 This is a multi-part message in MIME format. --Boundary_(ID_6xatc77rW6rqQlG6ltLVQA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please see my comments below. Gary Winiger wrote: >> This case - Sg3 utilities 1.25 - has been moved here to PSARC from LSARC. >> >> Please direct email conversations to this list going forward. >> > > And do you believe it still stands as self review? > There seem to be actual questions that are architectural > not answered in the spec. Viz: > > >From Darren.Moffat@Sun.COM Tue Nov 4 06:24:18 2008 > > How do these commands interact with the existing SCSI tools, libraries > on Solaris ? Are there any risks to running these commands on devices > managed by Solaris ? > Yes, the commands are sent through the USCSICMD interface, they may either inquiry or modify the information on SCSI devices, so there may be risks I think. > Do all these commands require privilege to run ? If so which privileges > ? Is there an RBAC profile for them ? > I'm not familiar with RBAC, so let me try to answer your questions. These utilities should be run as superuser(root). However for a normal user, he may also be able to run but could fail due to insufficient permission to open the device files. So the required privilege are file_dac_read and file_dac_write, the RBAC profile is "Primary Administrator", am I correct? -Xiao > Gary.. > --Boundary_(ID_6xatc77rW6rqQlG6ltLVQA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please see my comments below.

Gary Winiger wrote: 
This case - Sg3 utilities 1.25 - has been moved here to PSARC from LSARC.

Please direct email conversations to this list going forward.
    

	And do you believe it still stands as self review?
	There seem to be actual questions that are architectural
	not answered in the spec.  Viz:

>From Darren.Moffat@Sun.COM Tue Nov  4 06:24:18 2008

How do these commands interact with the existing SCSI tools, libraries 
on Solaris ?   Are there any risks to running these commands on devices 
managed by Solaris ?
Yes,  the commands are sent through the USCSICMD interface, they may either inquiry or modify the information on SCSI devices,
so there may be risks I think. 
Do all these commands require privilege to run ?  If so which privileges 
?  Is there an RBAC profile for them ?
I'm not familiar with RBAC, so let me try to answer your questions.
These utilities should be run as superuser(root). However for a normal user, he may also be able to run but could fail due to insufficient
permission to open the device files.
So the required privilege are file_dac_read and file_dac_write, the RBAC profile is "Primary Administrator", am I correct?
-Xiao
Gary..
--Boundary_(ID_6xatc77rW6rqQlG6ltLVQA)-- From gww@eng.sun.com Wed Nov 5 18:03:06 2008 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 mA6236tR003555 for ; Wed, 5 Nov 2008 18:03:06 -0800 (PST) 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 mA6234Sh000330 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 5 Nov 2008 18:03:05 -0800 (PST) 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 <0K9W00L07314J500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 19:03:04 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9W002KY31473D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 19:03:04 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA6231FO039389; Wed, 05 Nov 2008 18:03:01 -0800 (PST) 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 mA6237q9010104; Wed, 05 Nov 2008 18:03:07 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mA6236uP010103; Wed, 05 Nov 2008 18:03:06 -0800 (PST) Date: Wed, 05 Nov 2008 18:03:06 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] To: gww@eng.sun.com, Xiao.L@sun.com Cc: PSARC-ext@sun.com, Mark.Carlson@sun.com, David.Zhang@sun.com Message-id: <200811060203.mA6236uP010103@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1212 > > Do all these commands require privilege to run ? If so which privileges > > ? Is there an RBAC profile for them ? > > > I'm not familiar with RBAC, so let me try to answer your questions. Ah, a learning opportunity ;-) I guess time to brush up on this significant feature that's been part of Solaris since S8. Perhaps your case owner will find resources to help you. There's certainly some information in the SAC Policies and Best Practices. See the references in the new ARC 20 questions PSARC/2008/625 Streamline ARC 20Q > These utilities should be run as superuser(root). Why uid 0 and all privileges? I'm sure the project team can do something to understand the commands and build appropriate Rights Profiles. > However for a normal > user, he may also be able to run but could fail due to insufficient > permission to open the device files. Is the normal user supposed to run these commands? > So the required privilege are file_dac_read and file_dac_write, the RBAC > profile is "Primary Administrator", am I correct? Not really. If the commands are for administrative use, they belong listed in appropriate Rights Profiles (either new or existing). Gary.. From James.McPherson@SUN.COM Wed Nov 5 18:18:44 2008 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 mA62Ihr3003794 for ; Wed, 5 Nov 2008 18:18:44 -0800 (PST) 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 mA62IPCK007734 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Nov 2008 10:18:42 +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 <0K9W005053R36W00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 18:18:39 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9W0077N3R2CH90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 05 Nov 2008 18:18:39 -0800 (PST) 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 mA62Ibi1028240 for ; Thu, 06 Nov 2008 02:18:37 +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 <0K9W006013Q9SN00@mail-apac.sun.com> (original mail from James.McPherson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 10:18:37 +0800 (SGT) Received: from blinder ([220.157.71.44]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9W004KT3QZ46O3@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 10:18:37 +0800 (SGT) Date: Thu, 06 Nov 2008 12:18:32 +1000 From: "James C. McPherson" Subject: Re: Sg3 utilities 1.25 [LSARC/2008/683 Self Review] In-reply-to: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> Sender: James.McPherson@SUN.COM To: Xiao.Li@SUN.COM Cc: PSARC-ext@SUN.COM, David.Zhang@SUN.COM Message-id: <20081106121832.00004552@blinder> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; i386-pc-solaris2.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811041331.mA4DVBiU015049@sac.sfbay.sun.com> Status: RO Content-Length: 1167 On Tue, 04 Nov 2008 05:31:11 -0800 (PST) Mark Carlson wrote: > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Sg3 utilities 1.25 > 1.2. Name of Document Author/Supplier: > Author: Xiao Li > 1.3 Date of This Document: > 04 November, 2008 > > 2. Project Summary > 2.1. Project Description > > This project introduces the package of Sg3 utilites 1.25 into > the SFW consolidation. > ... > file /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file > /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file > /usr/include/scsi/sg_cmds.h Uncommitted Header file > /usr/include/scsi/sg_pt.h Uncommitted Header Where are these header files? I do not see them in the case materials directory. I'm also concerned that this case provides another, overlapping method of using uscsi(7I) apart from libscsi and libses. James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog From Xiao.L@sun.com Wed Nov 5 22:18:08 2008 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 mA66I77I009608 for ; Wed, 5 Nov 2008 22:18:08 -0800 (PST) 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 mA66I1KV012099 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 Nov 2008 14:18:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9W0080VEU51X00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Nov 2008 22:18:05 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9W002F3EU1R880@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 Nov 2008 22:18:05 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA66I16e019288 for ; Thu, 06 Nov 2008 06:18:01 +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 <0K9W00301EQQEY00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 Nov 2008 14:18:01 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9W0010KETZ2B90@mail-apac.sun.com>; Thu, 06 Nov 2008 14:18:00 +0800 (SGT) Date: Thu, 06 Nov 2008 14:20:16 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811060203.mA6236uP010103@marduk.eng.sun.com> Sender: Xiao.L@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, Mark.Carlson@sun.com, David.Zhang@sun.com Message-id: <49128CA0.50702@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BXkvgGyvmmSj/acFrDhLGw)" X-PMX-Version: 5.4.1.325704 References: <200811060203.mA6236uP010103@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 4723 This is a multi-part message in MIME format. --Boundary_(ID_BXkvgGyvmmSj/acFrDhLGw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please see my comments below. Gary Winiger wrote: >>> Do all these commands require privilege to run ? If so which privileges >>> ? Is there an RBAC profile for them ? >>> >>> >> I'm not familiar with RBAC, so let me try to answer your questions. >> > > Ah, a learning opportunity ;-) I guess time to brush up > on this significant feature that's been part of Solaris > since S8. Perhaps your case owner will find resources to > help you. There's certainly some information in the SAC > Policies and Best Practices. See the references in the > new ARC 20 questions PSARC/2008/625 Streamline ARC 20Q > Thanks for your kindly information. > >> These utilities should be run as superuser(root). >> > > Why uid 0 and all privileges? I'm sure the project team > can do something to understand the commands and build appropriate > Rights Profiles. > > >> However for a normal >> user, he may also be able to run but could fail due to insufficient >> permission to open the device files. >> > > Is the normal user supposed to run these commands? > No, they should be run by administrator. > >> So the required privilege are file_dac_read and file_dac_write, the RBAC >> profile is "Primary Administrator", am I correct? >> > > Not really. If the commands are for administrative use, they > belong listed in appropriate Rights Profiles (either new or > existing). > I did some investigation on Solaris RBAC, I hope I could answer your questions now. The required privilege should be sys_config, sys_devices, and the profile should be "File System Management". Thanks, -Xiao > Gary.. > --Boundary_(ID_BXkvgGyvmmSj/acFrDhLGw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please see my comments below.

Gary Winiger wrote: 
Do all these commands require privilege to run ?  If so which privileges 
?  Is there an RBAC profile for them ?
  
      
I'm not familiar with RBAC, so let me try to answer your questions.
    

	Ah, a learning opportunity ;-)  I guess time to brush up
	on this significant feature that's been part of Solaris
	since S8.  Perhaps your case owner will find resources to
	help you.  There's certainly some information in the SAC
	Policies and Best Practices.  See the references in the
	new ARC 20 questions PSARC/2008/625 Streamline ARC 20Q
Thanks for your kindly information.
  
These utilities should be run as superuser(root).
    

	Why uid 0 and all privileges?  I'm sure the project team
	can do something to understand the commands and build appropriate
	Rights Profiles.

  
						    However for a normal 
user, he may also be able to run but could fail due to insufficient
permission to open the device files.
    

	Is the normal user supposed to run these commands?
No, they should be run by administrator.
  
So the required privilege are file_dac_read and file_dac_write, the RBAC 
profile is "Primary Administrator", am I correct?
    

	Not really.  If the commands are for administrative use, they
	belong listed in appropriate Rights Profiles (either new or
	existing).
I did some investigation on Solaris RBAC, I hope I could answer your questions now.
The required privilege should be sys_config, sys_devices, and the profile should be "File System Management".
Thanks,
-Xiao
Gary..
--Boundary_(ID_BXkvgGyvmmSj/acFrDhLGw)-- From gdamore@sun.com Thu Nov 6 07:00:28 2008 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 mA6F0Rs2014823 for ; Thu, 6 Nov 2008 07:00:27 -0800 (PST) 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 mA6F0PUq040578 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Nov 2008 08:00:27 -0700 (MST) 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 <0K9X0060P30Q3600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 07:00:26 -0800 (PST) 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 <0K9X005UP30QCS10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 07:00:26 -0800 (PST) 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 mA6F0Q0q014959 for ; Thu, 06 Nov 2008 07:00:26 -0800 (PST) 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 <0K9X00A012ZU8D00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 07:00:26 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9X003S630IM090@fe-sfbay-09.sun.com>; Thu, 06 Nov 2008 07:00:18 -0800 (PST) Date: Thu, 06 Nov 2008 06:55:20 -0800 From: "Garrett D'Amore" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 FastTrack timeout 11/12/2008] In-reply-to: <200811052248.mA5MmsEO009728@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: Mark.Carlson@sun.com, PSARC-ext@sun.com, David.Zhang@sun.com, Xiao.L@sun.com Message-id: <49130558.6030900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811052248.mA5MmsEO009728@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 9828 This project is delivering man pages in section 8? Is there any precedent for section 8 man pages in Solaris? (As opposed to section 1m, which is where these kinds of things normally go on Solaris.) -- Garrett Gary Winiger wrote: >>> Please direct email conversations to this list going forward. >>> >> And do you believe it still stands as self review? >> > > At the request of the case owner, I've changed this to > a fast track and set the timer for 12 Nov. > A reply of the spec is below. > > Gary.. > ====== > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Sg3 utilities 1.25 > 1.2. Name of Document Author/Supplier: > Author: Xiao Li > 1.3 Date of This Document: > 04 November, 2008 > > 2. Project Summary > 2.1. Project Description > > This project introduces the package of Sg3 utilites 1.25 into the > SFW consolidation. > > 4. Technical Description > > The sg3_utils package contains utilities that send SCSI commands to > devices. As well as devices on transports traditionally associated > with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and > the SCSI Parallel Interface(SPI)) and many other devices use SCSI > command sets. ATAPI cd/dvd drives and SATA disks that connect via a > translation layer or a bridge device are examples of devices that > use SCSI command sets. > There are about 32 command line utilities inside this package. > Command name Notes > ============ =================================================== > sg_get_config fetch features and profiles of a cd/dvd drive and/or > its current media > sg_ident default is to report (fetch) the device identifier. > With the '--set' option a new identifier is sent to > the device. > sg_inq fetch standard response, VPD pages or version > descriptors. Also can perform IDENTIFY (PACKET) > DEVICE ATA command. VPD page decoding also performed > by sg_vpd and sdparm. > sg_logs fetch log sense pages, decode standard and some vendor > pages > sg_luns fetch luns reported by a device (lun 0 or "well known > lu") > sg_modes fetch mode pages (output mainly in hex, to decode > output use sdparm) > sg_opcodes fetch supported SCSI commands or supported task > management functions > sg_persist control persistent reservations and report reservation > status > sg_prevent control media removal, mainly for those SCSI devices > which have removable media (e.g. CD/DVD and tape drives) > sg_raw send user supplied cdb > sg_rdac display or modify RDAC redundant controller mode page > sg_read_buffer read descriptors or data > sg_read_long read data from given lba which includes the block and > ECC data. > sg_readcap fetch the number of blocks and the individual block > size for disks and CD/DVD media > sg_reassign reassign a lba from one sector on a disk (typically > damaged) to a new (spare) sector. User data copied if > it is recoverable. > sg_requests fetch sense data from the given device. Modern uses > include getting a progress indication (e.g. during a > format) or finding the power condition state. > sg_rmsn Relatively new command added to SPC-3. Format of > response is vendor specific so this utility outputs > it in hex (default) or binary. > sg_rtpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_safte fetch information from a SAF-TE processor. > sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE > commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI > command. > sg_sat_set_features Sends ATA SET FEATURES command via SAT. > sg_senddiag Issues either a default self test or a short/extended > foreground/background self test. With no arguments it > uses RECEIVE DIAGNOSTIC RESULTS to list all supported > diagnostic pages. > sg_ses Fetches status diagnostic pages from, and sends some > control pages to, a SCSI Enclosure Services (SES) > device. > sg_start Controls the power condition state of a SCSI device. > Primary use is to spin up and down SCSI disks. Can > also load and eject removable media. > sg_stpg Specialized for multi-ported SCSI devices where one > port (or a group of them) is preferred for IO over > another (or others). > sg_sync Causes disk caches to be flushed to media. > sg_turs Issue one or more Test Unit Ready commands. Can be > used to time SCSI command overhead. > sg_verify reads indicated blocks on a SCSI disks, stops on the > first error found. Does not yield any data. Useful > for media scans. > sg_vpd Decodes standard and some vendor Vital Product Data > (VPD) pages. > sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from > "sg_modes -r") to the SCSI device. See sdparm for > another method of setting mode page parameters. > sg_write_buffer write data; can be used to download firmware. > sg_write_long writes to a lba, data which includes the block and > ECC data. Suitable data typically fetched by prior > sg_read_long utility. > 5. Interfaces > > Exported interface Classification Interface type > =============================== ============== ============== > SUNWsg3utils Uncommitted Package name > /usr/bin/sg_get_config Uncommitted Command > /usr/bin/sg_ident Uncommitted Command > /usr/bin/sg_inq Uncommitted Command > /usr/bin/sg_logs Uncommitted Command > /usr/bin/sg_luns Uncommitted Command > /usr/bin/sg_modes Uncommitted Command > /usr/bin/sg_opcodes Uncommitted Command > /usr/bin/sg_persist Uncommitted Command > /usr/bin/sg_prevent Uncommitted Command > /usr/bin/sg_raw Uncommitted Command > /usr/bin/sg_rdac Uncommitted Command > /usr/bin/sg_read_buffer Uncommitted Command > /usr/bin/sg_read_long Uncommitted Command > /usr/bin/sg_readcap Uncommitted Command > /usr/bin/sg_reassign Uncommitted Command > /usr/bin/sg_requests Uncommitted Command > /usr/bin/sg_rmsn Uncommitted Command > /usr/bin/sg_rtpg Uncommitted Command > /usr/bin/sg_safte Uncommitted Command > /usr/bin/sg_sat_identify Uncommitted Command > /usr/bin/sg_sat_set_features Uncommitted Command > /usr/bin/sg_senddiag Uncommitted Command > /usr/bin/sg_ses Uncommitted Command > /usr/bin/sg_start Uncommitted Command > /usr/bin/sg_stpg Uncommitted Command > /usr/bin/sg_sync Uncommitted Command > /usr/bin/sg_turs Uncommitted Command > /usr/bin/sg_verify Uncommitted Command > /usr/bin/sg_vpd Uncommitted Command > /usr/bin/sg_wr_mode Uncommitted Command > /usr/bin/sg_write_buffer Uncommitted Command > /usr/bin/sg_write_long Uncommitted Command > /usr/lib/libsgutils.so Private Symbolic link > /usr/lib/libsgutils.so.1 Private Symbolic link > /usr/lib/libsgutils.so.1.0.0 Private Shared library > /usr/lib/libsgutils.a Private Static library > /usr/lib/libsgutils.la Private Libtool library > file > /usr/include/scsi/sg_lib.h Uncommitted Header file > /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file > /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file > /usr/include/scsi/sg_cmds.h Uncommitted Header file > /usr/include/scsi/sg_pt.h Uncommitted Header file > /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_safte.8 Uncommitted Manpage > /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage > /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage > /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_persist.8 Uncommitted Manpage > /usr/share/man/man8/sg_ses.8 Uncommitted Manpage > /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage > /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage > /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage > /usr/share/man/man8/sg_luns.8 Uncommitted Manpage > /usr/share/man/man8/sg_requests.8 Uncommitted Manpage > /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage > /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage > /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage > /usr/share/man/man8/sg_start.8 Uncommitted Manpage > /usr/share/man/man8/sg_verify.8 Uncommitted Manpage > /usr/share/man/man8/sg_modes.8 Uncommitted Manpage > /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage > /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage > /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage > /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage > /usr/share/man/man8/sg_ident.8 Uncommitted Manpage > /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage > /usr/share/man/man8/sg_inq.8 Uncommitted Manpage > /usr/share/man/man8/sg_raw.8 Uncommitted Manpage > /usr/share/man/man8/sg_turs.8 Uncommitted Manpage > /usr/share/man/man8/sg_sync.8 Uncommitted Manpage > /usr/share/man/man8/sg_logs.8 Uncommitted Manpage > /usr/share/man/man8/sg_format.8 Uncommitted Manpage > /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage > /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage > > The following additional installed files are not interface. > > Additional document > ------------------- > N/A > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > From Xiao.L@sun.com Thu Nov 6 07:10:45 2008 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 mA6FAign014917 for ; Thu, 6 Nov 2008 07:10:44 -0800 (PST) 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 mA6FAg3Y022206 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 Nov 2008 07:10:44 -0800 (PST) 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 <0K9X00A0D3HWKF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 08:10:44 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9X002A83HUZY80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 08:10:43 -0700 (MST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA6FAf9n018705 for ; Thu, 06 Nov 2008 15:10:41 +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 <0K9X007013DDJZ00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 Nov 2008 23:10:41 +0800 (SGT) Received: from [192.168.0.137] ([124.64.31.112]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K9X0049B3H646J9@mail-apac.sun.com>; Thu, 06 Nov 2008 23:10:41 +0800 (SGT) Date: Thu, 06 Nov 2008 23:10:20 +0800 From: Xiao Li Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 FastTrack timeout 11/12/2008] In-reply-to: <49130558.6030900@sun.com> Sender: Xiao.L@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , Mark.Carlson@sun.com, PSARC-ext@sun.com, David.Zhang@sun.com Message-id: <491308DC.3070607@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y1/kiB5wQ7HjO0iXFmVSZw)" X-PMX-Version: 5.4.1.325704 References: <200811052248.mA5MmsEO009728@marduk.eng.sun.com> <49130558.6030900@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 37881 This is a multi-part message in MIME format. --Boundary_(ID_y1/kiB5wQ7HjO0iXFmVSZw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT We've already discussed this in another thread. Please refer to the following: On 11/05/08 00:22, Alan Coopersmith wrote: > > >>> Gary Winiger wrote: > > >>> > >>> > >>>>> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >>> > >>>>> >>> >> > >>>> Perhaps I missed it, but my recollection was that there was >> > >>>> no man8 section. Did it get reintroduced? >> > >>>> >> > > >>> > > >>> Only as bugs by projects which fail to correctly deliver admin man pages > > >>> under the SysV section 1m instead of the BSD section 8. > > >>> > > >>> > > > Sorry I'm confused. Are you suggesting me to put the manpage under > > /usr/share/man/man1m? > > Yes - man pages which BSD-style systems (including Linux) put under man8 > are installed under man1m on Solaris & other SysV-style systems. Unless they've been overridden, there is adequate case precedent for the project team to follow. In specific see: PSARC/1999/555 Getting with the Freeware Program PSARC/2000/488 Solaris/Linux Commands Compatibility PSARC/2005/185 Enabling serendipitous discovery PSARC/2005/220 New Public Taxonomy PSARC/2007/048 Include GNU coreutils 6.7 Your case owner should point you to the relevant precedent. Gary.. Garrett D'Amore wrote: > This project is delivering man pages in section 8? Is there any > precedent for section 8 man pages in Solaris? (As opposed to section > 1m, which is where these kinds of things normally go on Solaris.) > > -- Garrett > > Gary Winiger wrote: >>>> Please direct email conversations to this list going forward. >>>> >>> And do you believe it still stands as self review? >>> >> >> At the request of the case owner, I've changed this to a fast >> track and set the timer for 12 Nov. >> A reply of the spec is below. >> >> Gary.. >> ====== >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Sg3 utilities 1.25 >> 1.2. Name of Document Author/Supplier: >> Author: Xiao Li >> 1.3 Date of This Document: >> 04 November, 2008 >> >> 2. Project Summary >> 2.1. Project Description >> >> This project introduces the package of Sg3 utilites 1.25 into >> the SFW consolidation. >> 4. Technical Description >> >> The sg3_utils package contains utilities that send SCSI commands to >> devices. As well as devices on transports traditionally associated >> with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and >> the SCSI Parallel Interface(SPI)) and many other devices use SCSI >> command sets. ATAPI cd/dvd drives and SATA disks that connect via a >> translation layer or a bridge device are examples of devices that >> use SCSI command sets. >> There are about 32 command line utilities inside this package. >> Command name Notes >> ============ =================================================== >> sg_get_config fetch features and profiles of a cd/dvd drive >> and/or >> its current media >> sg_ident default is to report (fetch) the device identifier. >> With the '--set' option a new identifier is sent to >> the device. >> sg_inq fetch standard response, VPD pages or version >> descriptors. Also can perform IDENTIFY (PACKET) >> DEVICE ATA command. VPD page decoding also performed >> by sg_vpd and sdparm. >> sg_logs fetch log sense pages, decode standard and some >> vendor >> pages >> sg_luns fetch luns reported by a device (lun 0 or "well known >> lu") >> sg_modes fetch mode pages (output mainly in hex, to decode >> output use sdparm) >> sg_opcodes fetch supported SCSI commands or supported task >> management functions >> sg_persist control persistent reservations and report reservation >> status >> sg_prevent control media removal, mainly for those SCSI devices >> which have removable media (e.g. CD/DVD and tape drives) >> sg_raw send user supplied cdb >> sg_rdac display or modify RDAC redundant controller mode page >> sg_read_buffer read descriptors or data >> sg_read_long read data from given lba which includes the block >> and >> ECC data. >> sg_readcap fetch the number of blocks and the individual block >> size for disks and CD/DVD media >> sg_reassign reassign a lba from one sector on a disk (typically >> damaged) to a new (spare) sector. User data copied if >> it is recoverable. >> sg_requests fetch sense data from the given device. Modern uses >> include getting a progress indication (e.g. during a >> format) or finding the power condition state. >> sg_rmsn Relatively new command added to SPC-3. Format of >> response is vendor specific so this utility outputs >> it in hex (default) or binary. >> sg_rtpg Specialized for multi-ported SCSI devices where one >> port (or a group of them) is preferred for IO over >> another (or others). >> sg_safte fetch information from a SAF-TE processor. >> sg_sat_identify Send ATA IDENTIFY DEVICE or IDENTIFY PACKET >> DEVICE >> commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI >> command. >> sg_sat_set_features Sends ATA SET FEATURES command via SAT. >> sg_senddiag Issues either a default self test or a short/extended >> foreground/background self test. With no arguments it >> uses RECEIVE DIAGNOSTIC RESULTS to list all supported >> diagnostic pages. >> sg_ses Fetches status diagnostic pages from, and sends some >> control pages to, a SCSI Enclosure Services (SES) >> device. >> sg_start Controls the power condition state of a SCSI device. >> Primary use is to spin up and down SCSI disks. Can >> also load and eject removable media. >> sg_stpg Specialized for multi-ported SCSI devices where one >> port (or a group of them) is preferred for IO over >> another (or others). >> sg_sync Causes disk caches to be flushed to media. >> sg_turs Issue one or more Test Unit Ready commands. Can be >> used to time SCSI command overhead. >> sg_verify reads indicated blocks on a SCSI disks, stops on the >> first error found. Does not yield any data. Useful >> for media scans. >> sg_vpd Decodes standard and some vendor Vital Product Data >> (VPD) pages. >> sg_wr_mode writes mode pages supplied in ASCII hex (e.g. from >> "sg_modes -r") to the SCSI device. See sdparm for >> another method of setting mode page parameters. >> sg_write_buffer write data; can be used to download firmware. >> sg_write_long writes to a lba, data which includes the block and >> ECC data. Suitable data typically fetched by prior >> sg_read_long utility. >> 5. Interfaces >> >> Exported interface Classification Interface type >> =============================== ============== ============== >> SUNWsg3utils Uncommitted Package name >> /usr/bin/sg_get_config Uncommitted Command >> /usr/bin/sg_ident Uncommitted Command >> /usr/bin/sg_inq Uncommitted Command >> /usr/bin/sg_logs Uncommitted Command >> /usr/bin/sg_luns Uncommitted Command >> /usr/bin/sg_modes Uncommitted Command >> /usr/bin/sg_opcodes Uncommitted Command >> /usr/bin/sg_persist Uncommitted Command >> /usr/bin/sg_prevent Uncommitted Command >> /usr/bin/sg_raw Uncommitted Command >> /usr/bin/sg_rdac Uncommitted Command >> /usr/bin/sg_read_buffer Uncommitted Command >> /usr/bin/sg_read_long Uncommitted Command >> /usr/bin/sg_readcap Uncommitted Command >> /usr/bin/sg_reassign Uncommitted Command >> /usr/bin/sg_requests Uncommitted Command >> /usr/bin/sg_rmsn Uncommitted Command >> /usr/bin/sg_rtpg Uncommitted Command >> /usr/bin/sg_safte Uncommitted Command >> /usr/bin/sg_sat_identify Uncommitted Command >> /usr/bin/sg_sat_set_features Uncommitted Command >> /usr/bin/sg_senddiag Uncommitted Command >> /usr/bin/sg_ses Uncommitted Command >> /usr/bin/sg_start Uncommitted Command >> /usr/bin/sg_stpg Uncommitted Command >> /usr/bin/sg_sync Uncommitted Command >> /usr/bin/sg_turs Uncommitted Command >> /usr/bin/sg_verify Uncommitted Command >> /usr/bin/sg_vpd Uncommitted Command >> /usr/bin/sg_wr_mode Uncommitted Command >> /usr/bin/sg_write_buffer Uncommitted Command >> /usr/bin/sg_write_long Uncommitted Command >> /usr/lib/libsgutils.so Private Symbolic link >> /usr/lib/libsgutils.so.1 Private Symbolic link >> /usr/lib/libsgutils.so.1.0.0 Private Shared library >> /usr/lib/libsgutils.a Private Static library >> /usr/lib/libsgutils.la Private Libtool library >> file >> /usr/include/scsi/sg_lib.h Uncommitted Header file >> /usr/include/scsi/sg_cmds_extra.h Uncommitted Header file >> /usr/include/scsi/sg_cmds_basic.h Uncommitted Header file >> /usr/include/scsi/sg_cmds.h Uncommitted Header file >> /usr/include/scsi/sg_pt.h Uncommitted Header file >> /usr/share/man/man8/sg_read_long.8 Uncommitted Manpage >> /usr/share/man/man8/sg_safte.8 Uncommitted Manpage >> /usr/share/man/man8/sg_senddiag.8 Uncommitted Manpage >> /usr/share/man/man8/sg_wr_mode.8 Uncommitted Manpage >> /usr/share/man/man8/sg_stpg.8 Uncommitted Manpage >> /usr/share/man/man8/sg_persist.8 Uncommitted Manpage >> /usr/share/man/man8/sg_ses.8 Uncommitted Manpage >> /usr/share/man/man8/sg_opcodes.8 Uncommitted Manpage >> /usr/share/man/man8/sg_get_config.8 Uncommitted Manpage >> /usr/share/man/man8/sg_read_buffer.8 Uncommitted Manpage >> /usr/share/man/man8/sg_luns.8 Uncommitted Manpage >> /usr/share/man/man8/sg_requests.8 Uncommitted Manpage >> /usr/share/man/man8/sg_prevent.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rdac.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rtpg.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sat_identify.8 Uncommitted Manpage >> /usr/share/man/man8/sg_start.8 Uncommitted Manpage >> /usr/share/man/man8/sg_verify.8 Uncommitted Manpage >> /usr/share/man/man8/sg_modes.8 Uncommitted Manpage >> /usr/share/man/man8/sg_readcap.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sat_set_features.8 Uncommitted Manpage >> /usr/share/man/man8/sg_rmsn.8 Uncommitted Manpage >> /usr/share/man/man8/sg3_utils.8 Uncommitted Manpage >> /usr/share/man/man8/sg_ident.8 Uncommitted Manpage >> /usr/share/man/man8/sg_vpd.8 Uncommitted Manpage >> /usr/share/man/man8/sg_inq.8 Uncommitted Manpage >> /usr/share/man/man8/sg_raw.8 Uncommitted Manpage >> /usr/share/man/man8/sg_turs.8 Uncommitted Manpage >> /usr/share/man/man8/sg_sync.8 Uncommitted Manpage >> /usr/share/man/man8/sg_logs.8 Uncommitted Manpage >> /usr/share/man/man8/sg_format.8 Uncommitted Manpage >> /usr/share/man/man8/sg_reassign.8 Uncommitted Manpage >> /usr/share/man/man8/sg_write_long.8 Uncommitted Manpage >> /usr/share/man/man8/sg_write_buffer.8 Uncommitted Manpage >> >> The following additional installed files are not interface. >> >> Additional document >> ------------------- >> N/A >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: Automatic >> 6.6. ARC Exposure: open >> >> > --Boundary_(ID_y1/kiB5wQ7HjO0iXFmVSZw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT We've already discussed this in another thread. Please refer to the following:

On 11/05/08 00:22, Alan Coopersmith wrote:

> >>> Gary Winiger wrote:
> >>>   
  
> >>>>>     /usr/share/man/man8/sg_read_long.8	Uncommitted	Manpage
> >>>>>       
      
> >>>> 	Perhaps I missed it, but my recollection was that there was
> >>>> 	no man8 section.  Did it get reintroduced?
> >>>>     
    
> >>>
> >>> Only as bugs by projects which fail to correctly deliver admin man pages
> >>> under the SysV section 1m instead of the BSD section 8.
> >>>
> >>>     
  
> > Sorry I'm confused. Are you suggesting me to put the manpage under
> > /usr/share/man/man1m?

> 
> Yes - man pages which BSD-style systems (including Linux) put under man8
> are installed under man1m on Solaris & other SysV-style systems.


	Unless they've been overridden, there is adequate case precedent
	for the project team to follow.  In specific see:
PSARC/1999/555 Getting with the Freeware Program
PSARC/2000/488 Solaris/Linux Commands Compatibility
PSARC/2005/185 Enabling serendipitous discovery
PSARC/2005/220  New Public Taxonomy
PSARC/2007/048  Include GNU coreutils 6.7

	Your case owner should point you to the relevant precedent.

Gary..


Garrett D'Amore wrote:
This project is delivering man pages in section 8?  Is there any precedent for section 8 man pages in Solaris?  (As opposed to section 1m, which is where these kinds of things normally go on Solaris.)

   -- Garrett

Gary Winiger wrote:
Please direct email conversations to this list going forward.
     
    And do you believe it still stands as self review?
   
    
    At the request of the case owner, I've changed this to     a fast track and set the timer for 12 Nov.
    A reply of the spec is below.

Gary..
======
This information is Copyright 2008 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
     Sg3 utilities 1.25
    1.2. Name of Document Author/Supplier:
     Author:  Xiao Li
    1.3  Date of This Document:
    04 November, 2008

2. Project Summary
   2.1. Project Description

        This project introduces the package of Sg3 utilites 1.25 into the     SFW consolidation.
    4. Technical Description

    The sg3_utils package contains utilities that send SCSI commands to
    devices. As well as devices on transports traditionally associated
    with SCSI (e.g. Fibre Channel (FCP), Serial Attached SCSI (SAS) and
    the SCSI Parallel Interface(SPI)) and many other devices use SCSI
    command sets. ATAPI cd/dvd drives and SATA disks that connect via a
    translation layer or a bridge device are examples of devices that
    use SCSI command sets.
    There are about 32 command line utilities inside this package.
    Command name    Notes
    ============    ===================================================
    sg_get_config    fetch features and profiles of a cd/dvd drive and/or
            its current media
    sg_ident    default is to report (fetch) the device identifier.
            With the '--set' option a new identifier is sent to
            the device.
    sg_inq        fetch standard response, VPD pages or version
            descriptors. Also can perform IDENTIFY (PACKET)
            DEVICE ATA command. VPD page decoding also performed
            by sg_vpd and sdparm.
    sg_logs        fetch log sense pages, decode standard and some vendor
            pages
    sg_luns        fetch luns reported by a device (lun 0 or "well known
            lu")
    sg_modes    fetch mode pages (output mainly in hex, to decode
            output use sdparm)
    sg_opcodes    fetch supported SCSI commands or supported task
            management functions
    sg_persist    control persistent reservations and report reservation
            status
    sg_prevent    control media removal, mainly for those SCSI devices
            which have removable media (e.g. CD/DVD and tape drives)
    sg_raw        send user supplied cdb
    sg_rdac        display or modify RDAC redundant controller mode page
    sg_read_buffer    read descriptors or data
    sg_read_long    read data from given lba which includes the block and
            ECC data.
    sg_readcap    fetch the number of blocks and the individual block
            size for disks and CD/DVD media
    sg_reassign    reassign a lba from one sector on a disk (typically
            damaged) to a new (spare) sector. User data copied if
            it is recoverable.
    sg_requests    fetch sense data from the given device. Modern uses
            include getting a progress indication (e.g. during a
            format) or finding the power condition state.
    sg_rmsn        Relatively new command added to SPC-3. Format of
            response is vendor specific so this utility outputs
            it in hex (default) or binary.
    sg_rtpg        Specialized for multi-ported SCSI devices where one
            port (or a group of them) is preferred for IO over
            another (or others).
    sg_safte    fetch information from a SAF-TE processor.
    sg_sat_identify    Send ATA IDENTIFY DEVICE or IDENTIFY PACKET DEVICE
            commands via the SAT ATA PASS-THROUGH (16 or 12) SCSI
            command.
    sg_sat_set_features      Sends ATA SET FEATURES command via SAT.
    sg_senddiag    Issues either a default self test or a short/extended
            foreground/background self test. With no arguments it
            uses RECEIVE DIAGNOSTIC RESULTS to list all supported
            diagnostic pages.
    sg_ses        Fetches status diagnostic pages from, and sends some
            control pages to, a SCSI Enclosure Services (SES)
            device.
    sg_start    Controls the power condition state of a SCSI device.
            Primary use is to spin up and down SCSI disks. Can
            also load and eject removable media.
    sg_stpg        Specialized for multi-ported SCSI devices where one
            port (or a group of them) is preferred for IO over
            another (or others).
    sg_sync        Causes disk caches to be flushed to media.
    sg_turs        Issue one or more Test Unit Ready commands. Can be
            used to time SCSI command overhead.
    sg_verify    reads indicated blocks on a SCSI disks, stops on the
            first error found. Does not yield any data. Useful
            for media scans.
    sg_vpd        Decodes standard and some vendor Vital Product Data
            (VPD) pages.
    sg_wr_mode    writes mode pages supplied in ASCII hex (e.g. from
            "sg_modes -r") to the  SCSI device. See sdparm for
            another method of setting mode page parameters.
    sg_write_buffer    write data; can be used to download firmware.
    sg_write_long    writes to a lba, data which includes the block and
            ECC data. Suitable data typically fetched by prior
            sg_read_long utility.
5. Interfaces

    Exported interface            Classification    Interface type
    ===============================    ==============    ==============
    SUNWsg3utils            Uncommitted    Package    name
    /usr/bin/sg_get_config        Uncommitted    Command
    /usr/bin/sg_ident            Uncommitted    Command
    /usr/bin/sg_inq            Uncommitted    Command
    /usr/bin/sg_logs            Uncommitted    Command
    /usr/bin/sg_luns            Uncommitted    Command
    /usr/bin/sg_modes            Uncommitted    Command
    /usr/bin/sg_opcodes            Uncommitted    Command
    /usr/bin/sg_persist            Uncommitted    Command
    /usr/bin/sg_prevent            Uncommitted    Command
    /usr/bin/sg_raw            Uncommitted    Command
    /usr/bin/sg_rdac            Uncommitted    Command
    /usr/bin/sg_read_buffer        Uncommitted    Command
    /usr/bin/sg_read_long        Uncommitted    Command
    /usr/bin/sg_readcap            Uncommitted    Command
    /usr/bin/sg_reassign        Uncommitted    Command
    /usr/bin/sg_requests        Uncommitted    Command
    /usr/bin/sg_rmsn            Uncommitted    Command
    /usr/bin/sg_rtpg            Uncommitted    Command
    /usr/bin/sg_safte            Uncommitted    Command
    /usr/bin/sg_sat_identify        Uncommitted    Command
    /usr/bin/sg_sat_set_features    Uncommitted    Command
    /usr/bin/sg_senddiag        Uncommitted    Command
    /usr/bin/sg_ses            Uncommitted    Command
    /usr/bin/sg_start            Uncommitted    Command
    /usr/bin/sg_stpg            Uncommitted    Command
    /usr/bin/sg_sync            Uncommitted    Command
    /usr/bin/sg_turs            Uncommitted    Command
    /usr/bin/sg_verify            Uncommitted    Command
    /usr/bin/sg_vpd            Uncommitted    Command
    /usr/bin/sg_wr_mode            Uncommitted    Command
    /usr/bin/sg_write_buffer        Uncommitted    Command
    /usr/bin/sg_write_long        Uncommitted    Command
    /usr/lib/libsgutils.so        Private        Symbolic link
    /usr/lib/libsgutils.so.1        Private        Symbolic link
    /usr/lib/libsgutils.so.1.0.0    Private        Shared library
    /usr/lib/libsgutils.a        Private        Static library
    /usr/lib/libsgutils.la        Private        Libtool library
    file
    /usr/include/scsi/sg_lib.h        Uncommitted    Header file
    /usr/include/scsi/sg_cmds_extra.h    Uncommitted    Header file
    /usr/include/scsi/sg_cmds_basic.h    Uncommitted    Header file
    /usr/include/scsi/sg_cmds.h        Uncommitted    Header file
    /usr/include/scsi/sg_pt.h        Uncommitted    Header file
    /usr/share/man/man8/sg_read_long.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_safte.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_senddiag.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_wr_mode.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_stpg.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_persist.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_ses.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_opcodes.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_get_config.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_read_buffer.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_luns.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_requests.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_prevent.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_rdac.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_rtpg.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_sat_identify.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_start.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_verify.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_modes.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_readcap.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_sat_set_features.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_rmsn.8    Uncommitted    Manpage
    /usr/share/man/man8/sg3_utils.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_ident.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_vpd.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_inq.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_raw.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_turs.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_sync.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_logs.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_format.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_reassign.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_write_long.8    Uncommitted    Manpage
    /usr/share/man/man8/sg_write_buffer.8    Uncommitted    Manpage
 
  The following additional installed files are not interface.

         Additional document
         -------------------
     N/A
     6. Resources and Schedule
    6.4. Steering Committee requested information
       6.4.1. Consolidation C-team Name:
        SFW
    6.5. ARC review type: Automatic
    6.6. ARC Exposure: open

 

--Boundary_(ID_y1/kiB5wQ7HjO0iXFmVSZw)-- From Mark.Carlson@sun.com Mon Nov 10 11:36:40 2008 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 mAAJadDN012929 for ; Mon, 10 Nov 2008 11:36:40 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAAJaHHF027195 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 10 Nov 2008 19:36:38 GMT 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 <0KA400F0LUH1US00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 11:36:37 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA400802UH0LRC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 11:36:36 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAAJaZPO023912 for ; Mon, 10 Nov 2008 19:36:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA400601SEKNY00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 12:36:35 -0700 (MST) Received: from Macintosh-252.local ([129.150.36.241]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA400A59UGU9WD0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 12:36:31 -0700 (MST) Date: Mon, 10 Nov 2008 12:36:29 -0700 From: "Mark A. Carlson" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683] Materials Update In-reply-to: <49128CA0.50702@sun.com> Sender: Mark.Carlson@sun.com To: psarc-ext@sun.com Cc: Grant Zhang , xiao li - Sun Microsystems - Beijing China , David.Zhang@sun.com Message-id: <49188D3D.5030300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811060203.mA6236uP010103@marduk.eng.sun.com> <49128CA0.50702@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 457 I have put in the case directory updated materials from the project team: sac:/shared/sac/Archives/CaseLog/arc/PSARC/2008/683 14 % ls *.txt sg3utils-fasttrack.txt sg3utils-indiana-checklist.txt The major changes include,: All the commands now moved from "/usr/bin" to "/usr/sbin" All libtool libraries and static libraries removed All header files removed All the manpages now moved from "/usr/share/man/man8" to "/usr/share/man/man1" -- mark From gdamore@sun.com Mon Nov 10 11:39:15 2008 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 mAAJdFAI012952 for ; Mon, 10 Nov 2008 11:39:15 -0800 (PST) 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 mAAJdEoq024948 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 10 Nov 2008 11:39:14 -0800 (PST) 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 <0KA40002PULE8T00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 12:39:14 -0700 (MST) 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 <0KA400LJPULCHK20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 12:39:12 -0700 (MST) 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 mAAJdC68026803 for ; Mon, 10 Nov 2008 11:39:12 -0800 (PST) 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 <0KA400401U2AL500@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 11:39:12 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA4005URUL3U490@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Nov 2008 11:39:04 -0800 (PST) Date: Mon, 10 Nov 2008 11:33:49 -0800 From: "Garrett D'Amore" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683] Materials Update In-reply-to: <49188D3D.5030300@sun.com> Sender: Garrett.Damore@sun.com To: "Mark A. Carlson" Cc: psarc-ext@sun.com, Grant Zhang , xiao li - Sun Microsystems - Beijing China , David.Zhang@sun.com Message-id: <49188C9D.5020608@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811060203.mA6236uP010103@marduk.eng.sun.com> <49128CA0.50702@sun.com> <49188D3D.5030300@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 548 Mark A. Carlson wrote: > I have put in the case directory updated materials from the project team: > > sac:/shared/sac/Archives/CaseLog/arc/PSARC/2008/683 14 % ls *.txt > sg3utils-fasttrack.txt sg3utils-indiana-checklist.txt > > The major changes include,: > All the commands now moved from "/usr/bin" to "/usr/sbin" > All libtool libraries and static libraries removed > All header files removed > All the manpages now moved from "/usr/share/man/man8" to > "/usr/share/man/man1" Did you mean to say man1m? -- Garrett > > -- mark From gww@sac.sfbay.sun.com Mon Nov 10 15:08:53 2008 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 mAAN8rIj025540 for ; Mon, 10 Nov 2008 15:08:53 -0800 (PST) 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 mAAN8meY060279 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 10 Nov 2008 16:08:52 -0700 (MST) 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 <0KA5000094ASXN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Nov 2008 15:08:52 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA500I224AS7GB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Nov 2008 15:08:52 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAAN8nfR065187; Mon, 10 Nov 2008 15:08:49 -0800 (PST) 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 mAAN8nRf025535; Mon, 10 Nov 2008 15:08:49 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mAAN8nTx025534; Mon, 10 Nov 2008 15:08:49 -0800 (PST) Date: Mon, 10 Nov 2008 15:08:49 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] To: Xiao.L@sun.com, gww@eng.sun.com Cc: David.Zhang@sun.com, Mark.Carlson@sun.com, PSARC-ext@sun.com Message-id: <200811102308.mAAN8nTx025534@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1954 > > > Do all these commands require privilege to run ? If so which privileges > > > ? Is there an RBAC profile for them ? > > > > > I'm not familiar with RBAC, so let me try to answer your questions. > > Ah, a learning opportunity ;-) I guess time to brush up > on this significant feature that's been part of Solaris > since S8. Perhaps your case owner will find resources to > help you. There's certainly some information in the SAC > Policies and Best Practices. See the references in the > new ARC 20 questions PSARC/2008/625 Streamline ARC 20Q > > > These utilities should be run as superuser(root). > > Why uid 0 and all privileges? I'm sure the project team > can do something to understand the commands and build appropriate > Rights Profiles. > > > However for a normal > > user, he may also be able to run but could fail due to insufficient > > permission to open the device files. > > Is the normal user supposed to run these commands? > > > So the required privilege are file_dac_read and file_dac_write, the RBAC > > profile is "Primary Administrator", am I correct? > > Not really. If the commands are for administrative use, they > belong listed in appropriate Rights Profiles (either new or > existing). > I have put in the case directory updated materials from the project team: > > sac:/shared/sac/Archives/CaseLog/arc/PSARC/2008/683 14 % ls *.txt > sg3utils-fasttrack.txt sg3utils-indiana-checklist.txt > > The major changes include,: > All the commands now moved from "/usr/bin" to "/usr/sbin" > All libtool libraries and static libraries removed > All header files removed > All the manpages now moved from "/usr/share/man/man8" to > "/usr/share/man/man1" I'm wondering what happend to the thread about superuser and RBAC. Are these commands available to all users? Are they managed through some other existant mechanism? Am I off base and should just shut up? Gary.. From Richard.Matthews@sun.com Tue Nov 11 14:40:27 2008 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 mABMeQ5r008670 for ; Tue, 11 Nov 2008 14:40:27 -0800 (PST) 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 mABMeKuq018415 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Nov 2008 06:40:25 +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 <0KA600603XNB5J00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 15:40:23 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA60035RXNBL820@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 15:40:23 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mABMeNrm010765 for ; Tue, 11 Nov 2008 22:40:23 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA600401WKOZH00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 15:40:23 -0700 (MST) Received: from [129.152.9.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA600DNZXN4OND0@mail-amer.sun.com>; Tue, 11 Nov 2008 15:40:23 -0700 (MST) Date: Tue, 11 Nov 2008 16:40:16 -0600 From: Rick Matthews Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811102308.mAAN8nTx025534@sac.sfbay.sun.com> Sender: Richard.Matthews@sun.com To: Gary Winiger , psarc-ext@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <491A09D0.8040901@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_mSbGgyOIAtpYBYWM4rxmkA)" X-PMX-Version: 5.4.1.325704 References: <200811102308.mAAN8nTx025534@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 3454 This is a multi-part message in MIME format. --Boundary_(ID_mSbGgyOIAtpYBYWM4rxmkA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/10/08 17:08, Gary Winiger wrote: > > I'm wondering what happend to the thread about superuser and RBAC. > Are these commands available to all users? Are they managed through > some other existant mechanism? Am I off base and should just > shut up? > > Gary.. > Gary, Was Xiao's answer of 11/06/2008 sufficient? > (message trimmed) > Date: Thu, 06 Nov 2008 14:20:16 +0800 > From: xiao li - Sun Microsystems - Beijing China > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] > > I did some investigation on Solaris RBAC, I hope I could answer your > questions now. > The required privilege should be sys_config, sys_devices, and the > profile should be "File System Management". > Thanks, > -Xiao -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_mSbGgyOIAtpYBYWM4rxmkA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/10/08 17:08, Gary Winiger wrote:


<snip> 

	I'm wondering what happend to the thread about superuser and RBAC.
	Are these commands available to all users?  Are they managed through
	some other existant mechanism?  Am I off base and should just
	shut up?

Gary..
Gary,
  Was Xiao's answer of  11/06/2008 sufficient?

> (message trimmed)
> Date: Thu, 06 Nov 2008 14:20:16 +0800
> From: xiao li - Sun Microsystems - Beijing China <Xiao.L@sun.com>
> Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review]
>
> I did some investigation on Solaris RBAC, I hope I could answer your
> questions now.
> The required privilege should be sys_config, sys_devices, and the
> profile should be "File System Management".
> Thanks,
> -Xiao


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_mSbGgyOIAtpYBYWM4rxmkA)-- From gww@sac.sfbay.sun.com Tue Nov 11 15:34:28 2008 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 mABNYRsf010124 for ; Tue, 11 Nov 2008 15:34:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mABNYO6F005034 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Nov 2008 23:34:26 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KA700E0N05CQW00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 15:34:24 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA700BJT05B4510@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 15:34:23 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mABNYMIq046168; Tue, 11 Nov 2008 15:34:22 -0800 (PST) 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 mABNYMgp010122; Tue, 11 Nov 2008 15:34:22 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mABNYMtX010121; Tue, 11 Nov 2008 15:34:22 -0800 (PST) Date: Tue, 11 Nov 2008 15:34:22 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] To: Richard.Matthews@sun.com, gww@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200811112334.mABNYMtX010121@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1630 Rick, > Was Xiao's answer of 11/06/2008 sufficient? Is this an official project team reply and a spec update? Does it add all 32 commands to the File System Management Rights Profile? If so, I'm wondering what the user model is for these commands. Should only the system administrator be able to run sg_get_config, sg_opcodes? I'm unclear on which of these are modify/change commands and therefore restricted and which are view/read and don't need restriction. Do they all require privs=sys_config,sys_devices? Will those that require privileges run with limitprivs=sys_config,sys_devices? Do some require no privileges? .... > > I'm wondering what happend to the thread about superuser and RBAC. > > Are these commands available to all users? Are they managed through > > some other existant mechanism? Am I off base and should just > > shut up? Are these legitimate questions in the committe's view? Does the project team have more to specify? Unbelievable as it may be, I can just shut up ;-) Case owner, If you and the project need some consulting time with me, let's find a time to schedule it rather than for me to have direct non-arc email get queued for when I get back to it. > > Date: Thu, 06 Nov 2008 14:20:16 +0800 > > From: xiao li - Sun Microsystems - Beijing China > > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] > > > > I did some investigation on Solaris RBAC, I hope I could answer your > > questions now. > > The required privilege should be sys_config, sys_devices, and the > > profile should be "File System Management". Gary.. v From David.Zhang@Sun.COM Tue Nov 11 17:40:36 2008 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 mAC1eZeu014002 for ; Tue, 11 Nov 2008 17:40:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAC1eXDc011694 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Nov 2008 01:40:34 GMT 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 <0KA700J055ZKSG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:40:32 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA7003F55ZJLDD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:40:32 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAC1eUgf015490 for ; Wed, 12 Nov 2008 01:40:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA700E015TE6400@fe-emea-10.sun.com> (original mail from David.Zhang@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 12 Nov 2008 01:40:30 +0000 (GMT) Received: from [129.158.144.53] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA7008T35ZEJ950@fe-emea-10.sun.com>; Wed, 12 Nov 2008 01:40:30 +0000 (GMT) Date: Wed, 12 Nov 2008 09:38:00 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811112334.mABNYMtX010121@sac.sfbay.sun.com> Sender: David.Zhang@Sun.COM To: Gary Winiger Cc: Richard.Matthews@Sun.COM, psarc-ext@Sun.COM, Xiao.L@Sun.COM Message-id: <491A3378.6070705@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GN1/HwekOv6gi8WMDKGCag)" X-PMX-Version: 5.4.1.325704 References: <200811112334.mABNYMtX010121@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 5119 This is a multi-part message in MIME format. --Boundary_(ID_GN1/HwekOv6gi8WMDKGCag) Content-type: multipart/alternative; boundary="Boundary_(ID_uS6cnhpi3eocTjJQ+IyLXw)" --Boundary_(ID_uS6cnhpi3eocTjJQ+IyLXw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Add Xiao.l into this loop. David On 11/12/08 07:34, Gary Winiger wrote: > Rick, > > >> Was Xiao's answer of 11/06/2008 sufficient? >> > > Is this an official project team reply and a spec update? > Does it add all 32 commands to the File System Management > Rights Profile? If so, I'm wondering what the user model > is for these commands. Should only the system administrator > be able to run sg_get_config, sg_opcodes? I'm unclear on > which of these are modify/change commands and therefore restricted > and which are view/read and don't need restriction. Do they all > require privs=sys_config,sys_devices? Will those that require > privileges run with limitprivs=sys_config,sys_devices? > Do some require no privileges? .... > > >>> I'm wondering what happend to the thread about superuser and RBAC. >>> Are these commands available to all users? Are they managed through >>> some other existant mechanism? Am I off base and should just >>> shut up? >>> > > Are these legitimate questions in the committe's view? > Does the project team have more to specify? > Unbelievable as it may be, I can just shut up ;-) > > Case owner, > If you and the project need some consulting time with me, > let's find a time to schedule it rather than for me to have > direct non-arc email get queued for when I get back to it. > > >> > Date: Thu, 06 Nov 2008 14:20:16 +0800 >> > From: xiao li - Sun Microsystems - Beijing China >> > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] >> > >> > I did some investigation on Solaris RBAC, I hope I could answer your >> > questions now. >> > The required privilege should be sys_config, sys_devices, and the >> > profile should be "File System Management". >> > > Gary.. > v > > --Boundary_(ID_uS6cnhpi3eocTjJQ+IyLXw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Add Xiao.l into this loop.

David
On 11/12/08 07:34, Gary Winiger wrote: 
Rick,

  
  Was Xiao's answer of  11/06/2008 sufficient?
    

	Is this an official project team reply and a spec update?
	Does it add all 32 commands to the File System Management
	Rights Profile?  If so, I'm wondering what the user model
	is for these commands.  Should only the system administrator
	be able to run sg_get_config, sg_opcodes?  I'm unclear on
	which of these are modify/change commands and therefore restricted
	and which are view/read and don't need restriction.  Do they all
	require privs=sys_config,sys_devices?  Will those that require
	privileges run with limitprivs=sys_config,sys_devices?
	Do some require no privileges? ....

  
	I'm wondering what happend to the thread about superuser and RBAC.
	Are these commands available to all users?  Are they managed through
	some other existant mechanism?  Am I off base and should just
	shut up?
      

	Are these legitimate questions in the committe's view?
	Does the project team have more to specify?
	Unbelievable as it may be, I can just shut up ;-)

Case owner,
	If you and the project need some consulting time with me,
	let's find a time to schedule it rather than for me to have
	direct non-arc email get queued for when I get back to it.

  
 > Date: Thu, 06 Nov 2008 14:20:16 +0800
 > From: xiao li - Sun Microsystems - Beijing China <Xiao.L@sun.com>
 > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review]
 >
 > I did some investigation on Solaris RBAC, I hope I could answer your
 > questions now.
 > The required privilege should be sys_config, sys_devices, and the
 > profile should be "File System Management".
    

Gary..
v

--Boundary_(ID_uS6cnhpi3eocTjJQ+IyLXw)-- --Boundary_(ID_GN1/HwekOv6gi8WMDKGCag) Content-type: text/x-vcard; name=David_Zhang.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=David_Zhang.vcf begin:vcard fn:David Zhang n:Zhang;David email;internet:David.Zhang@Sun.COM tel;work:84341 version:2.1 end:vcard --Boundary_(ID_GN1/HwekOv6gi8WMDKGCag)-- From gww@sac.sfbay.sun.com Tue Nov 11 17:59:48 2008 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 mAC1xls6015339 for ; Tue, 11 Nov 2008 17:59:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAC1xisq022271 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Wed, 12 Nov 2008 01:59:47 GMT 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 <0KA700L056VL6500@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:59:45 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA7003Y26VLLCD0@brm-avmta-1.central.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:59:45 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAC1xfA2052904; Tue, 11 Nov 2008 17:59:41 -0800 (PST) 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 mAC1xfQG015295; Tue, 11 Nov 2008 17:59:41 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mAC1xfAn015294; Tue, 11 Nov 2008 17:59:41 -0800 (PST) Date: Tue, 11 Nov 2008 17:59:41 -0800 (PST) From: Gary Winiger Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] To: David.Zhang@sun.com, gww@sac.sfbay.sun.com Cc: Richard.Matthews@sun.com, Xiao.L@sun.com, psarc-ext@sun.com Message-id: <200811120159.mAC1xfAn015294@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 523 David, > Add Xiao.l into this loop. Are you saying that the Interest: list in the IAM file isn't working? If so, please have the case owner fix it, or if interest list processing is failing all together, the case owner needs to let SAC staff know so it can be resolved. Gary.. Name: Sg3 utilities 1.25 Submitter: Xiao Li Owner: Mark Carlson Interest: Xiao.Li@Sun.COM, David.Zhang@Sun.COM Status: waiting fast-track 11/12/2008 Comment: closed approved automatic 11/04/2008 Exposure: open Comment: From David.Zhang@sun.com Tue Nov 11 18:13:43 2008 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 mAC2DhPN015961 for ; Tue, 11 Nov 2008 18:13:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAC2Detm029331 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Nov 2008 02:13:42 GMT 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 <0KA7002017ITVU00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:13:41 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA7001DP7ISALE0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Tue, 11 Nov 2008 18:13:41 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAC2DeSh010075 for ; Wed, 12 Nov 2008 02:13:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA700G017B39E00@fe-emea-09.sun.com> (original mail from David.Zhang@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 12 Nov 2008 02:13:40 +0000 (GMT) Received: from [129.158.144.53] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA700I327INJ380@fe-emea-09.sun.com>; Wed, 12 Nov 2008 02:13:39 +0000 (GMT) Date: Wed, 12 Nov 2008 10:11:09 +0800 From: David Zhang Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <200811120159.mAC1xfAn015294@sac.sfbay.sun.com> Sender: David.Zhang@sun.com To: Gary Winiger Cc: Richard.Matthews@sun.com, Xiao.L@sun.com, psarc-ext@sun.com Message-id: <491A3B3D.9030504@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_+Ufl5lr/rzKeJcnzV3wdlQ)" X-PMX-Version: 5.4.1.325704 References: <200811120159.mAC1xfAn015294@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 3524 This is a multi-part message in MIME format. --Boundary_(ID_+Ufl5lr/rzKeJcnzV3wdlQ) Content-type: multipart/alternative; boundary="Boundary_(ID_rE4ybPqTeT90onx/P4v/5A)" --Boundary_(ID_rE4ybPqTeT90onx/P4v/5A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/12/08 09:59, Gary Winiger wrote: > David, > > >> Add Xiao.l into this loop. >> > > Are you saying that the Interest: list in the IAM file isn't > working? If so, please have the case owner fix it, or if > interest list processing is failing all together, the case > owner needs to let SAC staff know so it can be resolved. > There are 2 *Xiao Li* in Sun, the case owner is the second Xiao Li (*xiao.l*@sun.com). Since he is on-board later than the original one, his email was cut to Xiao.l@sun.com When you type Xiao.l into your thunderbird, Xiao.li can pop up at the first time. I add him in case he missed any information from the email loop. :) Regards, David > Gary.. > > Name: Sg3 utilities 1.25 > Submitter: Xiao Li > Owner: Mark Carlson > Interest: Xiao.Li@Sun.COM, David.Zhang@Sun.COM > Status: waiting fast-track 11/12/2008 > Comment: closed approved automatic 11/04/2008 > Exposure: open > Comment: > --Boundary_(ID_rE4ybPqTeT90onx/P4v/5A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/12/08 09:59, Gary Winiger wrote: 
David,

  
Add Xiao.l into this loop.
    

	Are you saying that the Interest: list in the IAM file isn't
	working?  If so, please have the case owner fix it, or if
	interest list processing is failing all together, the case
	owner needs to let SAC staff know so it can be resolved.
There are 2 Xiao Li in Sun, the case owner is the second Xiao Li (xiao.l@sun.com).
Since he is on-board later than the original one, his email was cut to Xiao.l@sun.com

When you type Xiao.l into your thunderbird, Xiao.li can pop up at the first time.

I add him in case he missed any information from the email loop. :)

Regards,
David
Gary..

Name:		Sg3 utilities 1.25
Submitter:	Xiao Li
Owner:		Mark Carlson
Interest:	Xiao.Li@Sun.COM, David.Zhang@Sun.COM
Status:         waiting fast-track 11/12/2008
Comment:        closed approved automatic 11/04/2008
Exposure:	open
Comment:

--Boundary_(ID_rE4ybPqTeT90onx/P4v/5A)-- --Boundary_(ID_+Ufl5lr/rzKeJcnzV3wdlQ) Content-type: text/x-vcard; name=David_Zhang.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=David_Zhang.vcf begin:vcard fn:David Zhang n:Zhang;David email;internet:David.Zhang@Sun.COM tel;work:84341 version:2.1 end:vcard --Boundary_(ID_+Ufl5lr/rzKeJcnzV3wdlQ)-- From Mark.Carlson@sun.com Tue Nov 11 22:38:22 2008 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 mAC6cMt1023547 for ; Tue, 11 Nov 2008 22:38:22 -0800 (PST) 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 mAC6cL4T041367 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Nov 2008 23:38:22 -0700 (MST) 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 <0KA700J0VJRWVV00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 23:38:20 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA700HVHJRWN820@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 23:38:20 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAC6cJZl014077 for ; Wed, 12 Nov 2008 06:38:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA700101JLYI400@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Nov 2008 23:38:19 -0700 (MST) Received: from Macintosh-252.local ([129.150.32.110]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA7007ANJRQ8J80@mail-amer.sun.com>; Tue, 11 Nov 2008 23:38:19 -0700 (MST) Date: Tue, 11 Nov 2008 23:38:13 -0700 From: "Mark A. Carlson" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <491A3B3D.9030504@Sun.COM> Sender: Mark.Carlson@sun.com To: David Zhang Cc: Gary Winiger , psarc-ext@sun.com, Xiao.L@sun.com, Richard.Matthews@sun.com Message-id: <491A79D5.6070306@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jNSh0juSnMf0y3bYpVPMgQ)" X-PMX-Version: 5.4.1.325704 References: <200811120159.mAC1xfAn015294@sac.sfbay.sun.com> <491A3B3D.9030504@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 3823 This is a multi-part message in MIME format. --Boundary_(ID_jNSh0juSnMf0y3bYpVPMgQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT IAM file has been corrected. -- mark David Zhang wrote: > On 11/12/08 09:59, Gary Winiger wrote: >> David, >> >> >>> Add Xiao.l into this loop. >>> >> >> Are you saying that the Interest: list in the IAM file isn't >> working? If so, please have the case owner fix it, or if >> interest list processing is failing all together, the case >> owner needs to let SAC staff know so it can be resolved. >> > There are 2 *Xiao Li* in Sun, the case owner is the second Xiao Li > (*xiao.l*@sun.com). > Since he is on-board later than the original one, his email was cut to > Xiao.l@sun.com > > When you type Xiao.l into your thunderbird, Xiao.li can pop up at the > first time. > > I add him in case he missed any information from the email loop. :) > > Regards, > David >> Gary.. >> >> Name: Sg3 utilities 1.25 >> Submitter: Xiao Li >> Owner: Mark Carlson >> Interest: Xiao.Li@Sun.COM, David.Zhang@Sun.COM >> Status: waiting fast-track 11/12/2008 >> Comment: closed approved automatic 11/04/2008 >> Exposure: open >> Comment: >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_jNSh0juSnMf0y3bYpVPMgQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT IAM file has been corrected.

-- mark

David Zhang wrote:
On 11/12/08 09:59, Gary Winiger wrote: 
David,

  
Add Xiao.l into this loop.
    

	Are you saying that the Interest: list in the IAM file isn't
	working?  If so, please have the case owner fix it, or if
	interest list processing is failing all together, the case
	owner needs to let SAC staff know so it can be resolved.
There are 2 Xiao Li in Sun, the case owner is the second Xiao Li (xiao.l@sun.com).
Since he is on-board later than the original one, his email was cut to Xiao.l@sun.com

When you type Xiao.l into your thunderbird, Xiao.li can pop up at the first time.

I add him in case he missed any information from the email loop. :)

Regards,
David
Gary..

Name:		Sg3 utilities 1.25
Submitter:	Xiao Li
Owner:		Mark Carlson
Interest:	Xiao.Li@Sun.COM, David.Zhang@Sun.COM
Status:         waiting fast-track 11/12/2008
Comment:        closed approved automatic 11/04/2008
Exposure:	open
Comment:	
  

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_jNSh0juSnMf0y3bYpVPMgQ)-- From Xiao.L@sun.com Wed Nov 12 01:26:49 2008 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 mAC9Qn6d000090 for ; Wed, 12 Nov 2008 01:26:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mAC9QkJv001697 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Nov 2008 01:26:49 -0800 (PST) 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 <0KA700001RKM9V00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 12 Nov 2008 01:26:46 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA700J30RKL7W90@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Wed, 12 Nov 2008 01:26:46 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAC9QicC024295 for ; Wed, 12 Nov 2008 09:26:44 +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 <0KA700D01RGDYO00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 12 Nov 2008 17:26:44 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KA7008AORKJFDL0@mail-apac.sun.com>; Wed, 12 Nov 2008 17:26:44 +0800 (SGT) Date: Wed, 12 Nov 2008 17:28:59 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <491A3378.6070705@Sun.COM> Sender: Xiao.L@sun.com To: Gary Winiger Cc: Richard.Matthews@sun.com, psarc-ext@sun.com Message-id: <491AA1DB.80108@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6v0umLYafdNTXvj+higvEQ)" X-PMX-Version: 5.4.1.325704 References: <200811112334.mABNYMtX010121@sac.sfbay.sun.com> <491A3378.6070705@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 5312 This is a multi-part message in MIME format. --Boundary_(ID_6v0umLYafdNTXvj+higvEQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary, I've verified all these commands by using ppriv -D. All of these commands need the privilege of "sys_devices" and run with euid=0. Thanks and regards, -Xiao David Zhang wrote: > Add Xiao.l into this loop. > > David > On 11/12/08 07:34, Gary Winiger wrote: >> Rick, >> >> >>> Was Xiao's answer of 11/06/2008 sufficient? >>> >> >> Is this an official project team reply and a spec update? >> Does it add all 32 commands to the File System Management >> Rights Profile? If so, I'm wondering what the user model >> is for these commands. Should only the system administrator >> be able to run sg_get_config, sg_opcodes? I'm unclear on >> which of these are modify/change commands and therefore restricted >> and which are view/read and don't need restriction. Do they all >> require privs=sys_config,sys_devices? Will those that require >> privileges run with limitprivs=sys_config,sys_devices? >> Do some require no privileges? .... >> >> >>>> I'm wondering what happend to the thread about superuser and RBAC. >>>> Are these commands available to all users? Are they managed through >>>> some other existant mechanism? Am I off base and should just >>>> shut up? >>>> >> >> Are these legitimate questions in the committe's view? >> Does the project team have more to specify? >> Unbelievable as it may be, I can just shut up ;-) >> >> Case owner, >> If you and the project need some consulting time with me, >> let's find a time to schedule it rather than for me to have >> direct non-arc email get queued for when I get back to it. >> >> >>> > Date: Thu, 06 Nov 2008 14:20:16 +0800 >>> > From: xiao li - Sun Microsystems - Beijing China >>> > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] >>> > >>> > I did some investigation on Solaris RBAC, I hope I could answer your >>> > questions now. >>> > The required privilege should be sys_config, sys_devices, and the >>> > profile should be "File System Management". >>> >> >> Gary.. >> v >> >> > --Boundary_(ID_6v0umLYafdNTXvj+higvEQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gary,
I've verified all these commands by using ppriv -D.
All of these commands need the privilege of "sys_devices" and run with euid=0.
Thanks and regards,
-Xiao


David Zhang wrote:
Add Xiao.l into this loop.

David
On 11/12/08 07:34, Gary Winiger wrote: 
Rick,

  
  Was Xiao's answer of  11/06/2008 sufficient?
    

	Is this an official project team reply and a spec update?
	Does it add all 32 commands to the File System Management
	Rights Profile?  If so, I'm wondering what the user model
	is for these commands.  Should only the system administrator
	be able to run sg_get_config, sg_opcodes?  I'm unclear on
	which of these are modify/change commands and therefore restricted
	and which are view/read and don't need restriction.  Do they all
	require privs=sys_config,sys_devices?  Will those that require
	privileges run with limitprivs=sys_config,sys_devices?
	Do some require no privileges? ....

  
	I'm wondering what happend to the thread about superuser and RBAC.
	Are these commands available to all users?  Are they managed through
	some other existant mechanism?  Am I off base and should just
	shut up?
      

	Are these legitimate questions in the committe's view?
	Does the project team have more to specify?
	Unbelievable as it may be, I can just shut up ;-)

Case owner,
	If you and the project need some consulting time with me,
	let's find a time to schedule it rather than for me to have
	direct non-arc email get queued for when I get back to it.

  
 > Date: Thu, 06 Nov 2008 14:20:16 +0800
 > From: xiao li - Sun Microsystems - Beijing China <Xiao.L@sun.com>
 > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review]
 >
 > I did some investigation on Solaris RBAC, I hope I could answer your
 > questions now.
 > The required privilege should be sys_config, sys_devices, and the
 > profile should be "File System Management".
    

Gary..
v

--Boundary_(ID_6v0umLYafdNTXvj+higvEQ)-- From Mark.Carlson@Sun.COM Wed Nov 12 11:34:36 2008 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 mACJYaDQ026236 for ; Wed, 12 Nov 2008 11:34:36 -0800 (PST) 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 mACJYZac008230 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Nov 2008 11:34:36 -0800 (PST) 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 <0KA800601JPNH200@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Nov 2008 12:34:35 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA800056JPN84A0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Nov 2008 12:34:35 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mACJYZcP028715 for ; Wed, 12 Nov 2008 19:34:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA800501J1URF00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Nov 2008 12:34:35 -0700 (MST) Received: from Macintosh-252.local ([129.150.34.178]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA800DXXJP08T50@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Nov 2008 12:34:18 -0700 (MST) Date: Wed, 12 Nov 2008 12:34:12 -0700 From: "Mark A. Carlson" Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] In-reply-to: <491AA1DB.80108@sun.com> Sender: Mark.Carlson@Sun.COM To: psarc-ext@Sun.COM Message-id: <491B2FB4.1020909@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YeZX3OrubnsjXM3N95xO8Q)" X-PMX-Version: 5.4.1.325704 References: <200811112334.mABNYMtX010121@sac.sfbay.sun.com> <491A3378.6070705@Sun.COM> <491AA1DB.80108@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 6365 This is a multi-part message in MIME format. --Boundary_(ID_YeZX3OrubnsjXM3N95xO8Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I have extended the timer to 19 November, 2008 at the request of PSARC members during today's meeting. -- mark xiao li - Sun Microsystems - Beijing China wrote: > Hi Gary, > I've verified all these commands by using ppriv -D. > All of these commands need the privilege of "sys_devices" and run with > euid=0. > Thanks and regards, > -Xiao > > > David Zhang wrote: >> Add Xiao.l into this loop. >> >> David >> On 11/12/08 07:34, Gary Winiger wrote: >>> Rick, >>> >>> >>>> Was Xiao's answer of 11/06/2008 sufficient? >>>> >>> >>> Is this an official project team reply and a spec update? >>> Does it add all 32 commands to the File System Management >>> Rights Profile? If so, I'm wondering what the user model >>> is for these commands. Should only the system administrator >>> be able to run sg_get_config, sg_opcodes? I'm unclear on >>> which of these are modify/change commands and therefore restricted >>> and which are view/read and don't need restriction. Do they all >>> require privs=sys_config,sys_devices? Will those that require >>> privileges run with limitprivs=sys_config,sys_devices? >>> Do some require no privileges? .... >>> >>> >>>>> I'm wondering what happend to the thread about superuser and RBAC. >>>>> Are these commands available to all users? Are they managed through >>>>> some other existant mechanism? Am I off base and should just >>>>> shut up? >>>>> >>> >>> Are these legitimate questions in the committe's view? >>> Does the project team have more to specify? >>> Unbelievable as it may be, I can just shut up ;-) >>> >>> Case owner, >>> If you and the project need some consulting time with me, >>> let's find a time to schedule it rather than for me to have >>> direct non-arc email get queued for when I get back to it. >>> >>> >>>> > Date: Thu, 06 Nov 2008 14:20:16 +0800 >>>> > From: xiao li - Sun Microsystems - Beijing China >>>> > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review] >>>> > >>>> > I did some investigation on Solaris RBAC, I hope I could answer your >>>> > questions now. >>>> > The required privilege should be sys_config, sys_devices, and the >>>> > profile should be "File System Management". >>>> >>> >>> Gary.. >>> v >>> >>> >> > ------------------------------------------------------------------------ > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_YeZX3OrubnsjXM3N95xO8Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I have extended the timer to 19 November, 2008 at the request of PSARC members during today's meeting.

-- mark

xiao li - Sun Microsystems - Beijing China wrote:
Hi Gary,
I've verified all these commands by using ppriv -D.
All of these commands need the privilege of "sys_devices" and run with euid=0.
Thanks and regards,
-Xiao


David Zhang wrote:
Add Xiao.l into this loop.

David
On 11/12/08 07:34, Gary Winiger wrote: 
Rick,

  
  Was Xiao's answer of  11/06/2008 sufficient?
    

	Is this an official project team reply and a spec update?
	Does it add all 32 commands to the File System Management
	Rights Profile?  If so, I'm wondering what the user model
	is for these commands.  Should only the system administrator
	be able to run sg_get_config, sg_opcodes?  I'm unclear on
	which of these are modify/change commands and therefore restricted
	and which are view/read and don't need restriction.  Do they all
	require privs=sys_config,sys_devices?  Will those that require
	privileges run with limitprivs=sys_config,sys_devices?
	Do some require no privileges? ....

  
	I'm wondering what happend to the thread about superuser and RBAC.
	Are these commands available to all users?  Are they managed through
	some other existant mechanism?  Am I off base and should just
	shut up?
      

	Are these legitimate questions in the committe's view?
	Does the project team have more to specify?
	Unbelievable as it may be, I can just shut up ;-)

Case owner,
	If you and the project need some consulting time with me,
	let's find a time to schedule it rather than for me to have
	direct non-arc email get queued for when I get back to it.

  
 > Date: Thu, 06 Nov 2008 14:20:16 +0800
 > From: xiao li - Sun Microsystems - Beijing China <Xiao.L@sun.com>
 > Subject: Re: Sg3 utilities 1.25 [PSARC/2008/683 Self Review]
 >
 > I did some investigation on Solaris RBAC, I hope I could answer your
 > questions now.
 > The required privilege should be sys_config, sys_devices, and the
 > profile should be "File System Management".
    

Gary..
v

  


_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
--Boundary_(ID_YeZX3OrubnsjXM3N95xO8Q)-- From Xiao.L@sun.com Wed Nov 12 22:38:50 2008 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 mAD6cn6W023347 for ; Wed, 12 Nov 2008 22:38:50 -0800 (PST) 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 mAD6cbLn017393 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 14:38:48 +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 <0KA900801EGHJ600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Nov 2008 22:38:41 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA9001BSEGGL960@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Nov 2008 22:38:41 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAD6cdIY021774 for ; Thu, 13 Nov 2008 06:38:39 +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 <0KA900E01EFGLZ00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:38:39 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KA9007FWEGE17M0@mail-apac.sun.com>; Thu, 13 Nov 2008 14:38:39 +0800 (SGT) Date: Thu, 13 Nov 2008 14:40:52 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: sg3 utilities 1.25 [PSARC/2008/683] Sender: Xiao.L@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com Message-id: <491BCBF4.3060007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 1464 Hi Gary, All of these commands need to open the device tree files with read and write permission. The device tree files are by design of solaris owned by root, the following is an example: # ls -l /devices/pci@0,0/pci1022,7458@1/pci11ab,11ab@1/disk@1,0:q,raw crw-r----- 1 root sys 27, 464 Nov 13 10:52 /devices/pci@0,0/pci1022,7458@1/pci11ab,11ab@1/disk@1,0:q,raw And according to the output of ppriv -lv (the verbose description of all the privileges on solaris): file_dac_write Allows a process to write a file or directory whose permission bits or ACL do not allow the process write permission. In order to write files owned by uid 0 in the absence of an effective uid of 0 ALL privileges are required. These commands then need to be run with euid=0. Besides, I've checked all these commands by running ppriv -D -s A=sys_devices -e sg_xxx /dev/rdsk/cxtxdxpx as root. It's testified that all these command need the privilege "sys_devices" only. The "System Administrator" is not a user, it's one of the existing rights profiles, we could grant it to any user or role as we want. These commands are by design for system administration, I think we should put them under the rights profile "File System Management" which is a supplementary rights profile of "System Administrator". So it will depend on the customers which user/role would run these commands, not restricted to superuser(root). Thanks and regards, -Xiao From Darren.Moffat@sun.com Thu Nov 13 01:57:34 2008 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 mAD9vXEF028854 for ; Thu, 13 Nov 2008 01:57:34 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAD9vSCt001382 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 09:57:32 GMT 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 <0KA900H03NNU5900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 01:57:30 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA900GMYNNT6910@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 01:57:30 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAD9vTn0015221 for ; Thu, 13 Nov 2008 09:57:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA900F01NFIJR00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 09:57:29 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA900G0NNNLRC20@fe-emea-09.sun.com>; Thu, 13 Nov 2008 09:57:24 +0000 (GMT) Date: Thu, 13 Nov 2008 09:57:21 +0000 From: Darren J Moffat Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491BCBF4.3060007@sun.com> Sender: Darren.Moffat@sun.com To: xiao li - Sun Microsystems - Beijing China Cc: Gary Winiger , PSARC-ext@sun.com Message-id: <491BFA01.9090106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <491BCBF4.3060007@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1075 xiao li - Sun Microsystems - Beijing China wrote: > The "System Administrator" is not a user, it's one of the existing > rights profiles, we could grant it to any user or role as we want. > These commands are by design for system administration, I think we > should put them under the rights profile "File System Management" > which is a supplementary rights profile of "System Administrator". > So it will depend on the customers which user/role would run these > commands, not restricted to superuser(root). Since this has NOTHING to do with "File Systems" I don't think that is an appropriate existing RBAC profile. I would like to see one or maybe two new profiles: "SCSI Device Info" Contains the non empty set of commands from this case that require privilege but are non destructive in all their modes of operation - ie they are "status/info" commands only. "SCSI Device Management" Contains all of "SCSI Device Info" (as an included profile if possible) plus any commands from this case that have a destructive or change capability. -- Darren J Moffat From gww@sac.sfbay.sun.com Thu Nov 13 11:03:30 2008 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 mADJ3UCT016517 for ; Thu, 13 Nov 2008 11:03:30 -0800 (PST) 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 mADJ3SEj005456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 11:03:30 -0800 (PST) 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 <0KAA00H0JCXSZ000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:03:28 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA007DFCXRHHC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:03:27 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADJ3Odk033550; Thu, 13 Nov 2008 11:03:24 -0800 (PST) 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 mADJ3OVq016514; Thu, 13 Nov 2008 11:03:24 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mADJ3OQg016513; Thu, 13 Nov 2008 11:03:24 -0800 (PST) Date: Thu, 13 Nov 2008 11:03:24 -0800 (PST) From: Gary Winiger Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] To: Darren.Moffat@sun.com, Xiao.L@sun.com Cc: PSARC-ext@sun.com, gww@eng.sun.com Message-id: <200811131903.mADJ3OQg016513@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1802 > > The "System Administrator" is not a user, it's one of the existing > > rights profiles, we could grant it to any user or role as we want. > > These commands are by design for system administration, I think we > > should put them under the rights profile "File System Management" > > which is a supplementary rights profile of "System Administrator". > > So it will depend on the customers which user/role would run these > > commands, not restricted to superuser(root). > > Since this has NOTHING to do with "File Systems" I don't think that is > an appropriate existing RBAC profile. I tend to agree. I've offered to help the project team through the case owner, but that's not come to fruition. Looking at the issues you and I have raised, I believe a higher bandwidth communication than email will help to converge this. Such as why is sys_devices required to run the view commands? And why are the modes restricted? What is the policy? Why is the policy appropriate? And as you say why File System Management? It is included in System Administrator, so why is that the appropriate set of Rights Profiles for these commands? Since the claim is required privileges, what about limitprivs? > I would like to see one or maybe two new profiles: > > "SCSI Device Info" Contains the non empty set of commands from this > case that require privilege but are non destructive in all their modes > of operation - ie they are "status/info" commands only. Perhaps after understanding the why of the device policy, the view routines may not need any Rights Profile at all. From (one of the Xiao Li's) email that showed crw-r----- 1 root sys sgid sys might be appropriate. Without the project team explaination of rationale for the existant policy, I can't judge. Gary.. From Mark.Carlson@sun.com Thu Nov 13 11:52:26 2008 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 mADJqPb9017292 for ; Thu, 13 Nov 2008 11:52:26 -0800 (PST) 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 mADJqP9F026502 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 12:52:25 -0700 (MST) 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 <0KAA00L03F7DBG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:52:25 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA007TKF7CHMD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:52:24 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mADJqOD4020114 for ; Thu, 13 Nov 2008 19:52:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00601E85P900@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:52:24 -0700 (MST) Received: from Macintosh-252.local ([209.125.196.70]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA009EDF7711F0@mail-amer.sun.com>; Thu, 13 Nov 2008 12:52:21 -0700 (MST) Date: Thu, 13 Nov 2008 12:52:19 -0700 From: "Mark A. Carlson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491BFA01.9090106@Sun.COM> Sender: Mark.Carlson@sun.com To: Darren J Moffat Cc: xiao li - Sun Microsystems - Beijing China , PSARC-ext@sun.com, Gary Winiger Message-id: <491C8573.9050607@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5mtlDJoXDP+mefPaqR6pWg)" X-PMX-Version: 5.4.1.325704 References: <491BCBF4.3060007@sun.com> <491BFA01.9090106@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 3234 This is a multi-part message in MIME format. --Boundary_(ID_5mtlDJoXDP+mefPaqR6pWg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'll ask the project team to revise the proposal this way. Does everyone agree this is the right approach? -- mark Darren J Moffat wrote: > xiao li - Sun Microsystems - Beijing China wrote: > >> The "System Administrator" is not a user, it's one of the existing >> rights profiles, we could grant it to any user or role as we want. >> These commands are by design for system administration, I think we >> should put them under the rights profile "File System Management" >> which is a supplementary rights profile of "System Administrator". >> So it will depend on the customers which user/role would run these >> commands, not restricted to superuser(root). >> > > Since this has NOTHING to do with "File Systems" I don't think that is > an appropriate existing RBAC profile. > > I would like to see one or maybe two new profiles: > > "SCSI Device Info" Contains the non empty set of commands from this > case that require privilege but are non destructive in all their modes > of operation - ie they are "status/info" commands only. > > "SCSI Device Management" Contains all of "SCSI Device Info" (as an > included profile if possible) plus any commands from this case that have > a destructive or change capability. > > > --Boundary_(ID_5mtlDJoXDP+mefPaqR6pWg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I'll ask the project team to revise the proposal this way.

Does everyone agree this is the right approach?

-- mark

Darren J Moffat wrote: 
xiao li - Sun Microsystems - Beijing China wrote:
  
The "System Administrator" is not a user, it's one of the existing
rights profiles, we could grant it to any user or role as we want.
These commands are by design for system administration, I think we
should put them under the rights profile "File System Management"
which is a supplementary rights profile of "System Administrator".
So it will depend on the customers which user/role would run these
commands, not restricted to superuser(root).
    

Since this has NOTHING to do with "File Systems" I don't think that is 
an appropriate existing RBAC profile.

I would like to see one or maybe two new profiles:

"SCSI Device Info"  Contains the non empty set of commands from this 
case that require privilege but are non destructive in all their modes 
of operation - ie they are "status/info" commands only.

"SCSI Device Management"   Contains all of "SCSI Device Info" (as an 
included profile if possible) plus any commands from this case that have 
a destructive or change capability.
--Boundary_(ID_5mtlDJoXDP+mefPaqR6pWg)-- From gww@eng.sun.com Thu Nov 13 12:07:09 2008 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 mADK79SL017978 for ; Thu, 13 Nov 2008 12:07:09 -0800 (PST) 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 mADK79LM034329 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 13:07:09 -0700 (MST) 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 <0KAA00G01FVW9J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:07:08 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00GFOFVW3S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:07:08 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADK756M047193; Thu, 13 Nov 2008 12:07:05 -0800 (PST) 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 mADK7MMt020637; Thu, 13 Nov 2008 12:07:22 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id mADK7M21020636; Thu, 13 Nov 2008 12:07:22 -0800 (PST) Date: Thu, 13 Nov 2008 12:07:22 -0800 (PST) From: Gary Winiger Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] To: Darren.Moffat@sun.com, Mark.Carlson@sun.com Cc: Xiao.L@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <200811132007.mADK7M21020636@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 336 > I'll ask the project team to revise the proposal this way. > > Does everyone agree this is the right approach? No, not without the answers to the various questions posed in the followup to Darren's mail. Of course, the committee can just tell me to shutup. When I asked at the meeting, that wasn't the response I got. Gary.. From Darren.Moffat@sun.com Thu Nov 13 12:19:27 2008 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 mADKJQCg018526 for ; Thu, 13 Nov 2008 12:19:26 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADKJFpc009529 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 20:19:25 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAA00203GGD7V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:19:25 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00GVBGGCWWA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 12:19:25 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mADKJOrJ001245 for ; Thu, 13 Nov 2008 20:19:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00501GDXDJ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:19:24 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00CB0GGAKUE0@fe-emea-10.sun.com>; Thu, 13 Nov 2008 20:19:23 +0000 (GMT) Date: Thu, 13 Nov 2008 20:19:22 +0000 From: Darren J Moffat Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <200811132007.mADK7M21020636@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Mark.Carlson@sun.com, Xiao.L@sun.com, PSARC-ext@sun.com Message-id: <491C8BCA.4000201@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 740 Gary Winiger wrote: >> I'll ask the project team to revise the proposal this way. >> >> Does everyone agree this is the right approach? > > No, not without the answers to the various questions > posed in the followup to Darren's mail. > > Of course, the committee can just tell me to shutup. > When I asked at the meeting, that wasn't the response > I got. I think this case should be marked as waiting need spec. I STRONGLY STRONGLY encourage the project team to work with either or both of Gary and I offline before a new spec is produced. I believe Gary has already offered his help and should be the first point of contact but if my timezone is better for the project team I'm happy to be the second. -- Darren J Moffat From Richard.Matthews@sun.com Thu Nov 13 13:49:49 2008 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 mADLnnGG021861 for ; Thu, 13 Nov 2008 13:49:49 -0800 (PST) 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 mADLnmqe021861 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 13:49:48 -0800 (PST) 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 <0KAA00609KMZID00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:49:47 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00M5IKMY2Z60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:49:46 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mADLnkxg000198 for ; Thu, 13 Nov 2008 21:49:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00I01K6A2G00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:49:46 -0700 (MST) Received: from [129.152.9.11] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00JDTKMTAV30@mail-amer.sun.com>; Thu, 13 Nov 2008 14:49:43 -0700 (MST) Date: Thu, 13 Nov 2008 15:49:41 -0600 From: Rick Matthews Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491C8BCA.4000201@Sun.COM> Sender: Richard.Matthews@sun.com To: Darren J Moffat Cc: Gary Winiger , Mark.Carlson@sun.com, Xiao.L@sun.com, PSARC-ext@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <491CA0F5.60307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 1858 On 11/13/08 14:19, Darren J Moffat wrote: > Gary Winiger wrote: >>> I'll ask the project team to revise the proposal this way. >>> >>> Does everyone agree this is the right approach? >> >> No, not without the answers to the various questions >> posed in the followup to Darren's mail. >> >> Of course, the committee can just tell me to shutup. >> When I asked at the meeting, that wasn't the response >> I got. > > I think this case should be marked as waiting need spec. I STRONGLY > STRONGLY encourage the project team to work with either or both of > Gary and I offline before a new spec is produced. I believe Gary has > already offered his help and should be the first point of contact but > if my timezone is better for the project team I'm happy to be the second. > Gary, I don't think you should be told to shut up. All, I'm interested in this from a far more general position. It didn't seem to me that the sg3 utilities did any more than access the device via its name in the file system. Access to this device shouldn't need to be controlled by the utility, as any program can also attempt to open the device, and send the appropriate commands to get the actions desired. If that is the case, isn't the permissions to access the device provided by Solaris adequate? If that is not the case, I'll continue watching this thread with interest. -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From carlsonj@phorcys.east.sun.com Thu Nov 13 14:00:27 2008 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 mADM0Q89023904 for ; Thu, 13 Nov 2008 14:00:26 -0800 (PST) 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 mADM0JGb025802; Fri, 14 Nov 2008 06:00:21 +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 <0KAA00D0FL4J4H00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 14:00:19 -0800 (PST) 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 <0KAA00C7OL4IRS00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 14:00:19 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mADM0Hm1027317; Thu, 13 Nov 2008 17:00:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mADM0HEW027314; Thu, 13 Nov 2008 17:00:17 -0500 (EST) Date: Thu, 13 Nov 2008 17:00:17 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CA0F5.60307@Sun.COM> To: Richard.Matthews@sun.com Cc: Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <18716.41841.512213.106363@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.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> Status: RO Content-Length: 1501 Rick Matthews writes: > I'm interested in this from a far more general position. It didn't > seem to me that > the sg3 utilities did any more than access the device via its name in > the file system. > Access to this device shouldn't need to be controlled by the utility, as > any program > can also attempt to open the device, and send the appropriate commands > to get the actions > desired. If that is the case, isn't the permissions to access the device > provided by Solaris > adequate? If that is not the case, I'll continue watching this thread > with interest. The issue isn't with the utilities themselves -- they don't (and certainly should not) check anything about permissions; the drivers must do that. The issue is about what minimal privileges need to be granted to the utilities in order to make them work, and what profile (if any) should have them in it. It's unclear to me what sort of user would ever be invoking these things. Without a usage model, it's hard to speculate on the right profile to use, or even if there is one. As Gary has noted, it looks like the required permissions (euid==0) specified by the project team may be in excess of what's actually required to make these things work on Solaris, so that's another issue to resolve. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Matthew.Jacob@sun.com Thu Nov 13 14:16:10 2008 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 mADMG9si026352 for ; Thu, 13 Nov 2008 14:16:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADMG5sk021917 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 22:16:08 GMT 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 <0KAA00L17LUUOZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:16:06 -0800 (PST) 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 <0KAA00GKPLUT44A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:16:05 -0800 (PST) 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 mADMG4Ml004297 for ; Thu, 13 Nov 2008 14:16:04 -0800 (PST) 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 <0KAA00701LNIOX00@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:16:04 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA0068FLUR3O20@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 14:16:04 -0800 (PST) Date: Thu, 13 Nov 2008 14:14:59 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <18716.41841.512213.106363@gargle.gargle.HOWL> Sender: Matthew.Jacob@sun.com To: James Carlson Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CA6E3.7090005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 1115 Piping up..... > > > It's unclear to me what sort of user would ever be invoking these > things. Without a usage model, it's hard to speculate on the right > profile to use, or even if there is one. > All sorts of users may want to use these utilities as Solaris doesn't fully enumerate what devices are attached (esp. if there is no extant driver for them). If you add the SANE scanner package, you need some mechanism to find SCSI based scanners. If you want to access a media changer that is otherwise not driven already via sgen usage, you would use these utilities and mtx to manipulate the changer. > As Gary has noted, it looks like the required permissions (euid==0) > specified by the project team may be in excess of what's actually > required to make these things work on Solaris, so that's another issue > to resolve. > > *shrug* - this doesn't seem all that different than attaching random USB dongles. It's the user's computer (if they have physical access to it) to plug a device into. It's up to Solaris to pick a sensible permissions model for the user to access their own devices. From carlsonj@phorcys.east.sun.com Thu Nov 13 14:30:13 2008 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 mADMUDjj000081 for ; Thu, 13 Nov 2008 14:30:13 -0800 (PST) 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 mADMU4Jj006406; Thu, 13 Nov 2008 14:30:07 -0800 (PST) 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 <0KAA0090FMI7TQ00@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 15:30:07 -0700 (MST) 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 <0KAA00MXBMI52N80@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 15:30:05 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mADMU4Qc027668; Thu, 13 Nov 2008 17:30:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mADMU4Uq027665; Thu, 13 Nov 2008 17:30:04 -0500 (EST) Date: Thu, 13 Nov 2008 17:30:04 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CA6E3.7090005@sun.com> To: Matthew Jacob Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <18716.43628.921.782776@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.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> Status: RO Content-Length: 2228 Matthew Jacob writes: > Piping up..... > > > > > > It's unclear to me what sort of user would ever be invoking these > > things. Without a usage model, it's hard to speculate on the right > > profile to use, or even if there is one. > > > All sorts of users may want to use these utilities as Solaris doesn't > fully enumerate what devices are attached (esp. if there is no extant > driver for them). If you add the SANE scanner package, you need some > mechanism to find SCSI based scanners. If you want to access a media > changer that is otherwise not driven already via sgen usage, you would > use these utilities and mtx to manipulate the changer. OK ... but does that same argument apply to *all* of the utilities? Are there users whom you'd grant access to one sort of (presumably safe) utility, but not to the others? It looks to me like a SCSI-3 grab-bag, which is what surprises me about the list, and the apparent application of a single profile. And are some of those things you're describing actually defects in other utilities, such as cfgadm? If so, then why not fix those utilities rather than telling users to run around on bare metal? > > As Gary has noted, it looks like the required permissions (euid==0) > > specified by the project team may be in excess of what's actually > > required to make these things work on Solaris, so that's another issue > > to resolve. > > > > > > *shrug* - this doesn't seem all that different than attaching random USB > dongles. It's the user's computer (if they have physical access to it) > to plug a device into. It's up to Solaris to pick a sensible permissions > model for the user to access their own devices. I don't think I understand that answer. We're talking about whether euid needs to be set to 0 in order for these utilities to work, or if some lesser level of privilege could be granted (such as setting egid) in order to get the same effect. How does that have anything to do with users inserting USB hardware? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Matthew.Jacob@sun.com Thu Nov 13 14:38:02 2008 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 mADMc2lN001382 for ; Thu, 13 Nov 2008 14:38:02 -0800 (PST) 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 mADMc18h009931 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 14:38:02 -0800 (PST) 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 <0KAA00A0DMVEE700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:38:02 -0700 (MST) 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 <0KAA00MRNMVD2T80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:38:01 -0700 (MST) 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 mADMc1RH007015 for ; Thu, 13 Nov 2008 14:38:01 -0800 (PST) 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 <0KAA00H01MTLWE00@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 14:38:01 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA0067QMVB3OB0@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 14:38:00 -0800 (PST) Date: Thu, 13 Nov 2008 14:36:55 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <18716.43628.921.782776@gargle.gargle.HOWL> Sender: Matthew.Jacob@sun.com To: James Carlson Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CAC07.8090808@sun.com> MIME-version: 1.0 Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 3705 James Carlson wrote: 
Matthew Jacob writes:
  
Piping up.....
    
It's unclear to me what sort of user would ever be invoking these
things.  Without a usage model, it's hard to speculate on the right
profile to use, or even if there is one.
  
      
All sorts of users may want to use these utilities as Solaris doesn't 
fully enumerate what devices are attached (esp. if there is no extant 
driver for them). If you add the SANE scanner package, you need some 
mechanism to find SCSI based scanners. If you want to access a media 
changer that is otherwise not driven already via sgen usage, you would 
use these utilities and mtx to manipulate the changer.
    

OK ... but does that same argument apply to *all* of the utilities?
Are there users whom you'd grant access to one sort of (presumably
safe) utility, but not to the others?  It looks to me like a SCSI-3
grab-bag, which is what surprises me about the list, and the apparent
application of a single profile.
sg3 (not SCSI-3) is indeed a grab bag. Doug Gilbert has grown it over the years and it's been darned useful.
And are some of those things you're describing actually defects in
other utilities, such as cfgadm?  If so, then why not fix those
utilities rather than telling users to run around on bare metal?
Why not indeed? However, at the risk of derailing this discussion, I'd like to point out that the import of a package that users are used to using elsewhere will solve problems in N-P complete time as opposed to waiting for things to be fixed which certainly won't happen in the same geologic time frame.
  
As Gary has noted, it looks like the required permissions (euid==0)
specified by the project team may be in excess of what's actually
required to make these things work on Solaris, so that's another issue
to resolve.

  
      
*shrug* - this doesn't seem all that different than attaching random USB 
dongles. It's the user's computer (if they have physical access to it) 
to plug a device into. It's up to Solaris to pick a sensible permissions 
model for the user to access their own devices.
    

I don't think I understand that answer.  We're talking about whether
euid needs to be set to 0 in order for these utilities to work, or if
some lesser level of privilege could be granted (such as setting egid)
in order to get the same effect.

How does that have anything to do with users inserting USB hardware?

I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris (which seems to be tuned towards user/developers, not restricted users), plug in a device to my machine, I expect reasonable permissions *or* automated to tools to use that device. Therefore, whatever permissions framework allows me to use this package of tools seems reasonable to expect.
From carlsonj@phorcys.east.sun.com Thu Nov 13 14:51:44 2008 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 mADMph7J004872 for ; Thu, 13 Nov 2008 14:51:44 -0800 (PST) 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 mADMpEAd021670; Fri, 14 Nov 2008 06:51: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 <0KAA00I0JNHXM000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 14:51:33 -0800 (PST) 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 <0KAA00CNGNHWRU30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 14:51:33 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mADMpVDf027947; Thu, 13 Nov 2008 17:51:31 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mADMpVus027944; Thu, 13 Nov 2008 17:51:31 -0500 (EST) Date: Thu, 13 Nov 2008 17:51:31 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CAC07.8090808@sun.com> To: Matthew Jacob Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <18716.44915.553221.835523@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.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> Status: RO Content-Length: 2662 Matthew Jacob writes: > sg3 (not SCSI-3) is indeed a grab bag. Doug Gilbert has grown it over > the years and it's been darned useful.
I wasn't questioning the utility of it at all. I can see that it's quite powerful and useful. > Why not indeed? However, at the risk of derailing this discussion, I'd > like to point out that the import of a package that users are used to > using elsewhere will solve problems in N-P complete time as opposed to > waiting for things to be fixed which certainly won't happen in the same > geologic time frame.
I can't tell whether a nondeterministic machine could solve those problems in polynomial time, or for that matter whether there are perhaps other utilities that solve the same problem, but I guess that's beside the point. What we're asking here is how the delivered features themselves are properly integrated with the rest of the existing Solaris features, notably Least Privilege and RBAC. If the answer is that they're just not integrated because that's ETOOHARD (which is what I *think* you're asserting), then perhaps architectural review is itself too hard. The safest and simplest thing by far to do would be to deliver them with no RBAC profile at all -- that is, simply fail to integrate with Solaris, and force the user to figure it out. That way, you wouldn't be accidentally granting access to harmful things (things that can cause privilege escalation) through an existing profile. That'd work, but the result over time of many projects doing this is that Solaris itself becomes incomplete: more and more things skip RBAC, omit auditing, and opt for init.d scripts rather than SMF. Eventually, we wind up with a trash pile of incomplete features. I guess I don't know whether we care about that. I would suggest that Darren and Gary do, which is why they spoke up. It's not to slow down a project or make it "geologic," but to find out what makes it complete. > I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris > (which seems to be tuned towards user/developers, not restricted > users), plug in a device to my machine, I expect reasonable permissions > *or* automated to tools to use that device. Therefore, whatever > permissions framework allows me to use this package of tools seems > reasonable to expect.
We're talking about privileges granted to a process, not how permissions on a device are set. They're different issues. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From bart.smaalders@sun.com Thu Nov 13 15:02:55 2008 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 mADN2t7N006326 for ; Thu, 13 Nov 2008 15:02:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mADN2ndD019045; Thu, 13 Nov 2008 15:02:50 -0800 (PST) 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 <0KAA0001BO0PKW00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 15:02:49 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00G9PO0O43D0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 15:02:48 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id mADN2mLU019999; Thu, 13 Nov 2008 23:02:48 +0000 (GMT) Date: Thu, 13 Nov 2008 15:02:45 -0800 From: Bart Smaalders Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <18716.44915.553221.835523@gargle.gargle.HOWL> To: James Carlson Cc: Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CB215.4040808@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 881 James Carlson wrote: > Matthew Jacob writes: >> I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris >> (which seems to be tuned towards user/developers, not restricted >> users), plug in a device to my machine, I expect reasonable permissions >> *or* automated to tools to use that device. Therefore, whatever >> permissions framework allows me to use this package of tools seems >> reasonable to expect.
> > We're talking about privileges granted to a process, not how > permissions on a device are set. They're different issues. > Perhaps one of the issues is that we don't seem to have a good profile for a essentially single user machine such as a workstation or laptop... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Nicolas.Williams@Sun.COM Thu Nov 13 15:07:36 2008 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 mADN7ZrE006439 for ; Thu, 13 Nov 2008 15:07:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mADN7UkL028979; Thu, 13 Nov 2008 15:07:30 -0800 (PST) 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 <0KAA0000XO8HRV00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 15:07:29 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00GKHO8G44E0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 15:07:28 -0800 (PST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mADN6nQS115217; Thu, 13 Nov 2008 17:06:49 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mADN6nDe115216; Thu, 13 Nov 2008 17:06:49 -0600 (CST) Date: Thu, 13 Nov 2008 17:06:49 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB215.4040808@Sun.COM> To: Bart Smaalders Cc: James Carlson , Matthew Jacob , Richard.Matthews@Sun.COM, Darren J Moffat , PSARC-ext@Sun.COM, Xiao.L@Sun.COM, Mark.Carlson@Sun.COM, Gary Winiger Message-id: <20081113230649.GP111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 853 On Thu, Nov 13, 2008 at 03:02:45PM -0800, Bart Smaalders wrote: > James Carlson wrote: > >Matthew Jacob writes: > >>I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris > >>(which seems to be tuned towards user/developers, not restricted > >>users), plug in a device to my machine, I expect reasonable permissions > >>*or* automated to tools to use that device. Therefore, whatever > >>permissions framework allows me to use this package of tools seems > >>reasonable to expect.
> > > >We're talking about privileges granted to a process, not how > >permissions on a device are set. They're different issues. > > > > Perhaps one of the issues is that we don't seem to have a good profile > for a essentially single user machine such as a workstation or laptop... Sure we do! Primary Administrator, Console User, ... Nico -- From Matthew.Jacob@sun.com Thu Nov 13 15:15:22 2008 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 mADNFL3V006724 for ; Thu, 13 Nov 2008 15:15:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mADNF7JK004503 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 15:15:21 -0800 (PST) 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 <0KAA00105OLB3O00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 15:15:11 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00G43OLB43E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 15:15:11 -0800 (PST) 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 mADNFB1k025170 for ; Thu, 13 Nov 2008 15:15:11 -0800 (PST) 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 <0KAA00B01OD0SI00@fe-sfbay-09.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 13 Nov 2008 15:15:11 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA000WJOKZNMB0@fe-sfbay-09.sun.com>; Thu, 13 Nov 2008 15:14:59 -0800 (PST) Date: Thu, 13 Nov 2008 15:13:52 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <18716.44915.553221.835523@gargle.gargle.HOWL> Sender: Matthew.Jacob@sun.com To: James Carlson Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CB4B0.4020606@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 3358 James Carlson wrote: > What we're asking here is how the delivered features themselves are > properly integrated with the rest of the existing Solaris features, > notably Least Privilege and RBAC. If the answer is that they're just > not integrated because that's ETOOHARD (which is what I *think* you're > asserting), then perhaps architectural review is itself too hard. > No, I'm not asserting ETOOHARD. I'm claiming that there needs to be a balance between architecturally correct and end-user useful. > The safest and simplest thing by far to do would be to deliver them > with no RBAC profile at all -- that is, simply fail to integrate with > Solaris, and force the user to figure it out. That way, you wouldn't > be accidentally granting access to harmful things (things that can > cause privilege escalation) through an existing profile. > > That'd work, but the result over time of many projects doing this is > that Solaris itself becomes incomplete: more and more things skip > RBAC, omit auditing, and opt for init.d scripts rather than SMF. > Eventually, we wind up with a trash pile of incomplete features. > Yes- this point is very well taken. > I guess I don't know whether we care about that. I would suggest that > Darren and Gary do, which is why they spoke up. It's not to slow down > a project or make it "geologic," but to find out what makes it complete. > Yes. The "geologic" observation on my part is that so far is that some issues have become so hard that to all intents and purposes change comes on the order of decades. That isn't to say that changes don't come and when the come they aren't valuable when complete- but the balance above isn't necessarily consciously struck. Perhaps what needs to happen here is the putative usefulness of the package not only in and of itself but as part of the overall "let's look friendly to people who use linux" needs to be balanced with: + Is it worth including at all? + Is it worth including even incomplete wrt RBAC? + Is it worth including if it takes a year to sort out RBAC and other issues? If these questions are answered by the submitters with some business case, then the architectural issues can be weighed properly. Secondarily should be the recognition that useful tools get put onto Solaris installations whether approved by Sun or not. If sg3_utils has a solaris piece already (haven't checked recently), people will just add it anyway. Perhaps another thing to make the inclusion of these packages easier is a "optional but unsupported because...." category which is just a documentation exercise. Like, we could say "sg3_utils is something you can add, but it doesn't meet the Solaris criteria of a, b, c which is why it's not part of the default release. You have been warned". > > >> I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris >> (which seems to be tuned towards user/developers, not restricted >> users), plug in a device to my machine, I expect reasonable permissions >> *or* automated to tools to use that device. Therefore, whatever >> permissions framework allows me to use this package of tools seems >> reasonable to expect.
>> > > We're talking about privileges granted to a process, not how > permissions on a device are set. They're different issues. > > Oh, yes, sorry. My bad. From Matthew.Jacob@sun.com Thu Nov 13 15:16:01 2008 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 mADNG16u006741 for ; Thu, 13 Nov 2008 15:16:01 -0800 (PST) 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 mADNFp0e024709 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 15:16:01 -0800 (PST) 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 <0KAA00D0LOMF9H00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:15:51 -0700 (MST) 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 <0KAA00MEZOMD2OA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:15:50 -0700 (MST) 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 mADNFnjr011182 for ; Thu, 13 Nov 2008 15:15:49 -0800 (PST) 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 <0KAA00B01OD0SI00@fe-sfbay-09.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:15:49 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA0009TOMCNMC0@fe-sfbay-09.sun.com>; Thu, 13 Nov 2008 15:15:49 -0800 (PST) Date: Thu, 13 Nov 2008 15:14:42 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB215.4040808@Sun.COM> Sender: Matthew.Jacob@sun.com To: Bart Smaalders Cc: James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CB4E2.40904@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 866 Bart Smaalders wrote: > James Carlson wrote: >> Matthew Jacob writes: >>> I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris >>> (which seems to be tuned towards user/developers, not restricted >>> users), plug in a device to my machine, I expect reasonable permissions >>> *or* automated to tools to use that device. Therefore, whatever >>> permissions framework allows me to use this package of tools seems >>> reasonable to expect.
>> >> We're talking about privileges granted to a process, not how >> permissions on a device are set. They're different issues. >> > > Perhaps one of the issues is that we don't seem to have a good profile > for a essentially single user machine such as a workstation or laptop... > Yes. Which is odd because the default OpenSolaris install on an x86 machine seems to be explicitly tuned to that model. From Mark.Carlson@sun.com Thu Nov 13 15:17:04 2008 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 mADNH37Z006760 for ; Thu, 13 Nov 2008 15:17:04 -0800 (PST) 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 mADNF3jj002501 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 07:17:02 +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 <0KAA0010NOOC6400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:17:00 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00GFPOOB40D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:17:00 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mADNGx4x028301 for ; Thu, 13 Nov 2008 23:16:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00801OL7N900@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:16:59 -0700 (MST) Received: from Macintosh-252.local ([129.150.33.206]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00AOKOO5RBD0@mail-amer.sun.com>; Thu, 13 Nov 2008 16:16:58 -0700 (MST) Date: Thu, 13 Nov 2008 16:16:51 -0700 From: "Mark A. Carlson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB215.4040808@Sun.COM> Sender: Mark.Carlson@sun.com To: Bart Smaalders Cc: James Carlson , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CB563.3000503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 1809 Bart Smaalders wrote: > James Carlson wrote: >> Matthew Jacob writes: >>> I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris >>> (which seems to be tuned towards user/developers, not restricted >>> users), plug in a device to my machine, I expect reasonable permissions >>> *or* automated to tools to use that device. Therefore, whatever >>> permissions framework allows me to use this package of tools seems >>> reasonable to expect.
>> >> We're talking about privileges granted to a process, not how >> permissions on a device are set. They're different issues. >> > > Perhaps one of the issues is that we don't seem to have a good profile > for a essentially single user machine such as a workstation or laptop... Yes, that would certainly help. It should be obvious that these are device administrator utilities, it's not unreasonable to have them all operate under one profile. If the members don't like the name of the profile that fits what is required, the team can make a new profile with the same permissions and a different name. As xiao said: All of these commands need to open the device tree files with read and write permission. The device tree files are by design of solaris owned by root, the following is an example: # ls -l /devices/pci@0,0/pci1022,7458@1/pci11ab,11ab@1/disk@1,0:q,raw crw-r----- 1 root sys 27, 464 Nov 13 10:52 /devices/pci@0,0/pci1022,7458@1/pci11ab,11ab@1/disk@1,0:q,raw So there really are no "read-only" (with respect to the device files) uses here. However, they may just read the actual SCSI device by sending read commands (requiring a write to the device). Since this is a familiarity case we need to be conscious of what the user experience is like on Linux and map that as appropriate to how Solaris works. -- mark From Nicolas.Williams@sun.com Thu Nov 13 15:24:25 2008 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 mADNOOND007206 for ; Thu, 13 Nov 2008 15:24:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADNOE7w000201; Thu, 13 Nov 2008 23:24:18 GMT 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 <0KAA00D03P0DTC00@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 16:24:13 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00MG5P0D2UC0@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 16:24:13 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mADNNYHT115230; Thu, 13 Nov 2008 17:23:34 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mADNNYHd115229; Thu, 13 Nov 2008 17:23:34 -0600 (CST) Date: Thu, 13 Nov 2008 17:23:34 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB4B0.4020606@sun.com> To: Matthew Jacob Cc: James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <20081113232333.GQ111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB4B0.4020606@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2092 On Thu, Nov 13, 2008 at 03:13:52PM -0800, Matthew Jacob wrote: > James Carlson wrote: > >What we're asking here is how the delivered features themselves are > >properly integrated with the rest of the existing Solaris features, > >notably Least Privilege and RBAC. If the answer is that they're just > >not integrated because that's ETOOHARD (which is what I *think* you're > >asserting), then perhaps architectural review is itself too hard. > > > No, I'm not asserting ETOOHARD. I'm claiming that there needs to be a > balance between architecturally correct and end-user useful. Sorry, what's the difference between "architecturally correct" and "end-user useful"? I don't see the difference. It seems that you're arguing that having sg3 on the system with zero integration is "end-user useful," and I agree, but having more than zero integration should be even more "end-user useful" for users that don't have the Primary Administrator profile. Now, on OpenSolaris systems the user that owns a particular system is likely to have the Primary Administrator profile, so for *them* any further integration of sg3 may well be pointless. > >I guess I don't know whether we care about that. I would suggest that > >Darren and Gary do, which is why they spoke up. It's not to slow down > >a project or make it "geologic," but to find out what makes it complete. > > > Yes. The "geologic" observation on my part is that so far is that some > issues have become so hard that to all intents and purposes change comes I don't see how looking at prof_attr(4) and deciding what profile each sg3 utility most naturally belongs to (or, if none seems appropriate, then creating new profiles as needed) is "so hard." It does depend on who's doing the integration. But hopefully submitters learn and it gets easier over time. > + Is it worth including at all? > + Is it worth including even incomplete wrt RBAC? > + Is it worth including if it takes a year to sort out RBAC and other > issues? You've gone from "geologic" to "a year," but you're still exagerating massively. Nico -- From Nicolas.Williams@sun.com Thu Nov 13 15:27:52 2008 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 mADNRp7q007550 for ; Thu, 13 Nov 2008 15:27:52 -0800 (PST) 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 mADNRhUB008475; Fri, 14 Nov 2008 07:27:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAA00M05P66H000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 15:27:42 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00CXPP65RW40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Nov 2008 15:27:42 -0800 (PST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mADNR2OE115237; Thu, 13 Nov 2008 17:27:02 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mADNR2I8115236; Thu, 13 Nov 2008 17:27:02 -0600 (CST) Date: Thu, 13 Nov 2008 17:27:02 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB563.3000503@sun.com> To: "Mark A. Carlson" Cc: Bart Smaalders , Xiao.L@sun.com, Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Matthew Jacob Message-id: <20081113232702.GR111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 711 On Thu, Nov 13, 2008 at 04:16:51PM -0700, Mark A. Carlson wrote: > Since this is a familiarity case we need to be conscious of what the user > experience is like on Linux and map that as appropriate to how Solaris > works. If the Linux user just runs "sudo sg_..." then nothing else need be done here from a single-user OpenSolaris perspective because the equivalent in OS is "pfexec sg_..." and the owner of a single-user OpenSolaris already gets the right to do that (via the Primary Administrator profile, which is granted to the account created at install time). Beyond single-user OpenSolaris systems (and yes, that is the focus _now_, but not forever), having suitable profiles would be nice. Nico -- From Matthew.Jacob@sun.com Thu Nov 13 15:33:26 2008 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 mADNXPgH008201 for ; Thu, 13 Nov 2008 15:33:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADNXNkK005086 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 23:33:24 GMT 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 <0KAA00E0HPFNHK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:33:23 -0700 (MST) 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 <0KAA00MDBPFM2OB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:33:22 -0700 (MST) 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 mADNXMqS027091 for ; Thu, 13 Nov 2008 15:33:22 -0800 (PST) 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 <0KAA00J01PCSPX00@fe-sfbay-09.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:33:22 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00BU1PFKYT20@fe-sfbay-09.sun.com>; Thu, 13 Nov 2008 15:33:21 -0800 (PST) Date: Thu, 13 Nov 2008 15:32:13 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081113232333.GQ111792@Sun.COM> Sender: Matthew.Jacob@sun.com To: Nicolas Williams Cc: James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491CB8FD.1070005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB4B0.4020606@sun.com> <20081113232333.GQ111792@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 1533 Nicolas Williams wrote: > On Thu, Nov 13, 2008 at 03:13:52PM -0800, Matthew Jacob wrote: > >> James Carlson wrote: >> >>> What we're asking here is how the delivered features themselves are >>> properly integrated with the rest of the existing Solaris features, >>> notably Least Privilege and RBAC. If the answer is that they're just >>> not integrated because that's ETOOHARD (which is what I *think* you're >>> asserting), then perhaps architectural review is itself too hard. >>> >>> >> No, I'm not asserting ETOOHARD. I'm claiming that there needs to be a >> balance between architecturally correct and end-user useful. >> > > Sorry, what's the difference between "architecturally correct" and > "end-user useful"? > > I don't see the difference. *shrug* > > >>> I guess I don't know whether we care about that. I would suggest that >>> Darren and Gary do, which is why they spoke up. It's not to slow down >>> a project or make it "geologic," but to find out what makes it complete. >>> >>> >> Yes. The "geologic" observation on my part is that so far is that some >> issues have become so hard that to all intents and purposes change comes >> > > I don't see how looking at prof_attr(4) and deciding what profile each > sg3 utility most naturally belongs to (or, if none seems appropriate, > then creating new profiles as needed) is "so hard." > Perhaps not. > > > You've gone from "geologic" to "a year," but you're still exagerating > massively. > > Don 't think so. From gdamore@sun.com Thu Nov 13 15:47:20 2008 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 mADNlJMB009056 for ; Thu, 13 Nov 2008 15:47:19 -0800 (PST) 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 mADNlEsM017318 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 07:47:16 +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 <0KAA00205Q2PIY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:47:13 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA001RRQ2OZE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:47:12 -0800 (PST) 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 mADNlCDP028582 for ; Thu, 13 Nov 2008 15:47:12 -0800 (PST) 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 <0KAA00L01MGZSX00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:47:12 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00BVTQ21YT70@fe-sfbay-09.sun.com>; Thu, 13 Nov 2008 15:46:51 -0800 (PST) Date: Thu, 13 Nov 2008 15:41:21 -0800 From: "Garrett D'Amore" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB563.3000503@sun.com> Sender: Garrett.Damore@sun.com To: "Mark A. Carlson" Cc: Bart Smaalders , James Carlson , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CBB21.4020601@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2049 It seems *awfully* strange to me that we feel obliged to integrate a set of command line utilities which are designed to provide raw access to a hardware bus to the command line. While I suppose some might argue that there are some precedents (pcitool) -- I think those precedents are somewhat limited, and generally have little chance for destructiveness. And, I don't believe I'm alone (but I may be in the minority) in my belief that generally this is the kind of detail users *don't* want to see. (If you look at other shrink wrapped OS', I think you'll find that neither Windows nor MacOS offer this kind of direct access to users.) The whole idea that we need to do this at all makes me believe that there is some other set of larger architectural gaps in the system. (Or is it the case that there aren't, and this is another case of "it ships on Linux so it shall ship on Solaris"? I hope not, because apart from some very specific diagnostic needs, I believe that Linux' inclusion of this in certain distributions is also a sign of architectural incompleteness in Linux itself.) While I agree that diagnostic utilities can be useful in trouble shooting certain problems (probably most often in development of new device drivers, etc.) I hope that we don't believe that these kinds of utilities are the sorts of things that average, or even advanced, Solaris users or developers are going to be expected to use. So with that in mind, I think I agree with Jim. The folks using these utilities should be smart enough to figure out to run the commands as root, without needing preconfigured RBAC. Just because a user logs in to the console, I don't think he should have access to the raw busses of the console devices (including USB, SCSI, and any 8042 style busses.) I don't think the failure to "automatically" support these utilities would represent any "feature gap" on Solaris. (But then again, I don't think a failure to "ship" these utilities represents any such feature gap either.) -- Garrett From Nicolas.Williams@sun.com Thu Nov 13 15:54:13 2008 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 mADNsDN2009411 for ; Thu, 13 Nov 2008 15:54:13 -0800 (PST) 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 mADNs9KU009707; Thu, 13 Nov 2008 16:54:09 -0700 (MST) 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 <0KAA00G0PQE92600@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 16:54:09 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00MBMQE72OC0@brm-avmta-1.central.sun.com>; Thu, 13 Nov 2008 16:54:07 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mADNrScj115250; Thu, 13 Nov 2008 17:53:28 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mADNrSwV115249; Thu, 13 Nov 2008 17:53:28 -0600 (CST) Date: Thu, 13 Nov 2008 17:53:28 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CBB21.4020601@sun.com> To: "Garrett D'Amore" Cc: "Mark A. Carlson" , Bart Smaalders , James Carlson , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <20081113235327.GS111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 415 On Thu, Nov 13, 2008 at 03:41:21PM -0800, Garrett D'Amore wrote: > It seems *awfully* strange to me that we feel obliged to integrate a set > of command line utilities which are designed to provide raw access to a > hardware bus to the command line. I don't think that's trange at all. It's a useful debug aid at the very least, and it may well be a useful integrator's tool for gluing things together as well. From Mark.Carlson@sun.com Thu Nov 13 15:58:20 2008 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 mADNwKtm009888 for ; Thu, 13 Nov 2008 15:58:20 -0800 (PST) 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 mADNwJ0N011450 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 16:58:19 -0700 (MST) 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 <0KAA00203QL6S200@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:58:18 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA00COYQL5RU70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 15:58:17 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mADNwHbQ029243 for ; Thu, 13 Nov 2008 23:58:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00G01QFN8000@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:58:17 -0700 (MST) Received: from Macintosh-252.local ([129.150.33.206]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00LDLQKL5AD0@mail-amer.sun.com>; Thu, 13 Nov 2008 16:58:00 -0700 (MST) Date: Thu, 13 Nov 2008 16:57:55 -0700 From: "Mark A. Carlson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081113235327.GS111792@Sun.COM> Sender: Mark.Carlson@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , Bart Smaalders , James Carlson , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CBF03.1010404@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Qbae/znaOAoktQx4B55fUw)" X-PMX-Version: 5.4.1.325704 References: <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 2181 This is a multi-part message in MIME format. --Boundary_(ID_Qbae/znaOAoktQx4B55fUw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT There is such a thing as a "storage developer" that needs these kind of tools. This doesn't imply any architectural gap in the OS. We supply tools for all kinds of developers, why all this angst for these storage developer tools? -- mark Nicolas Williams wrote: > On Thu, Nov 13, 2008 at 03:41:21PM -0800, Garrett D'Amore wrote: > >> It seems *awfully* strange to me that we feel obliged to integrate a set >> of command line utilities which are designed to provide raw access to a >> hardware bus to the command line. >> > > I don't think that's trange at all. It's a useful debug aid at the very > least, and it may well be a useful integrator's tool for gluing things > together as well. > --Boundary_(ID_Qbae/znaOAoktQx4B55fUw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT There is such a thing as a "storage developer" that needs these
kind of tools. This doesn't imply any architectural gap in the OS.
We supply tools for all kinds of developers, why all this angst for
these storage developer tools?

-- mark

Nicolas Williams wrote: 
On Thu, Nov 13, 2008 at 03:41:21PM -0800, Garrett D'Amore wrote:
  
It seems *awfully* strange to me that we feel obliged to integrate a set 
of command line utilities which are designed to provide raw access to a 
hardware bus to the command line.
    

I don't think that's trange at all.  It's a useful debug aid at the very
least, and it may well be a useful integrator's tool for gluing things
together as well.
--Boundary_(ID_Qbae/znaOAoktQx4B55fUw)-- From Matthew.Jacob@sun.com Thu Nov 13 16:05:55 2008 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 mAE05t1k010138 for ; Thu, 13 Nov 2008 16:05:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE05n4T022596 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 00:05:54 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAA0030XQXTMC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:05:53 -0800 (PST) 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 <0KAA00C83QXTMX80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:05:53 -0800 (PST) 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 mAE05qiA000465 for ; Thu, 13 Nov 2008 16:05:52 -0800 (PST) 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 <0KAA00701QR75E00@fe-sfbay-09.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:05:52 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00BI6QXRYTE0@fe-sfbay-09.sun.com>; Thu, 13 Nov 2008 16:05:52 -0800 (PST) Date: Thu, 13 Nov 2008 16:04:43 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081113235327.GS111792@Sun.COM> Sender: Matthew.Jacob@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CC09B.2040608@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 1180 Nicolas Williams wrote: > On Thu, Nov 13, 2008 at 03:41:21PM -0800, Garrett D'Amore wrote: > >> It seems *awfully* strange to me that we feel obliged to integrate a set >> of command line utilities which are designed to provide raw access to a >> hardware bus to the command line. >> > > I don't think that's trange at all. It's a useful debug aid at the very > least, and it may well be a useful integrator's tool for gluing things > together as well. > It isn't just a debug aid. Similar tools and libraries dependent upon those tools began shipping from Legato in 1994 because of lack of support within Solaris. As far as I know, they still ship, although they probably use sgen when available. This Legato thing isn't just a random user package. This is a major backup package that Sun used to OEM. It still generated 500$M/yr revenue for EMC. Repeated discussions with Sun over the years pointing out both Legato's discomfort (*and* Sun's discomfort- at one point they were even maintaining the tools I believe) over using raw access in this way never really went anywhere. So please don't tell me I'm exaggerating. I know precisely whereof I speak. From Nicolas.Williams@sun.com Thu Nov 13 16:11:54 2008 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 mAE0BrWE010174 for ; Thu, 13 Nov 2008 16:11:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE0BhaE026316; Fri, 14 Nov 2008 00:11:45 GMT 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 <0KAA0030BR7JLS00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 16:11:43 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAA001QJR7JZ410@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 16:11:43 -0800 (PST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mAE0B4jV115270; Thu, 13 Nov 2008 18:11:04 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mAE0B3B2115269; Thu, 13 Nov 2008 18:11:03 -0600 (CST) Date: Thu, 13 Nov 2008 18:11:03 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC09B.2040608@sun.com> To: Matthew Jacob Cc: "Garrett D'Amore" , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <20081114001103.GU111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1501 On Thu, Nov 13, 2008 at 04:04:43PM -0800, Matthew Jacob wrote: > It isn't just a debug aid. Similar tools and libraries dependent upon > those tools began shipping from Legato in 1994 because of lack of > support within Solaris. As far as I know, they still ship, although they > probably use sgen when available. > > This Legato thing isn't just a random user package. This is a major > backup package that Sun used to OEM. It still generated 500$M/yr revenue > for EMC. > > Repeated discussions with Sun over the years pointing out both Legato's > discomfort (*and* Sun's discomfort- at one point they were even > maintaining the tools I believe) over using raw access in this way never > really went anywhere. > > So please don't tell me I'm exaggerating. I know precisely whereof I speak. I thought you were exagerating about RBAC, or ARC process in general, not about how long it took to get here for completely unrelated reasons. I seriously doubt that the ARC had anything to do with why it took years for a proposal to integrate sg3 to come along. The truth is it's taken years for lots of very obvious integrations to happen, and only now are we getting around to it, but the ARC had nothing to do with why it took so long for us to get serious about integrating FOSS into Solaris. The ARC may have been seen as an impediment, but to be fair the SDF processes were tailored to a different business model, and the SDF has had to be modified as we've modified our business model. From Matthew.Jacob@sun.com Thu Nov 13 16:31:11 2008 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 mAE0VBKe010487 for ; Thu, 13 Nov 2008 16:31:11 -0800 (PST) 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 mAE0VBnw020930 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 16:31:11 -0800 (PST) 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 <0KAA00I09S3ZUK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 17:31:11 -0700 (MST) 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 <0KAA00M06S3Y3CF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 17:31:10 -0700 (MST) 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 mAE0VAYM002701 for ; Thu, 13 Nov 2008 16:31:10 -0800 (PST) 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 <0KAA00I01RNJN100@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:31:10 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA0095LS3X4I60@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 16:31:09 -0800 (PST) Date: Thu, 13 Nov 2008 16:29:59 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081114001103.GU111792@Sun.COM> Sender: Matthew.Jacob@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CC687.6060809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 2620 Nicolas Williams wrote: > On Thu, Nov 13, 2008 at 04:04:43PM -0800, Matthew Jacob wrote: > >> It isn't just a debug aid. Similar tools and libraries dependent upon >> those tools began shipping from Legato in 1994 because of lack of >> support within Solaris. As far as I know, they still ship, although they >> probably use sgen when available. >> >> This Legato thing isn't just a random user package. This is a major >> backup package that Sun used to OEM. It still generated 500$M/yr revenue >> for EMC. >> >> Repeated discussions with Sun over the years pointing out both Legato's >> discomfort (*and* Sun's discomfort- at one point they were even >> maintaining the tools I believe) over using raw access in this way never >> really went anywhere. >> >> So please don't tell me I'm exaggerating. I know precisely whereof I speak. >> > > I thought you were exagerating about RBAC, or ARC process in general, > not about how long it took to get here for completely unrelated reasons. > I seriously doubt that the ARC had anything to do with why it took years > for a proposal to integrate sg3 to come along. > > The truth is it's taken years for lots of very obvious integrations to > happen, and only now are we getting around to it, but the ARC had > nothing to do with why it took so long for us to get serious about > integrating FOSS into Solaris. The ARC may have been seen as an > impediment, but to be fair the SDF processes were tailored to a > different business model, and the SDF has had to be modified as we've > modified our business model. > Partly true. The continuing discussions on this ARC related alias suggests to me that the laudable concern about architectural issues still isn't quite as informed about the business model realities as it perhaps might be. The ARC process is, I agree, only part of the issue. Don't get me wrong- I strongly approve of the ARC process- it's one of the reasons why Sun is alive (still) and SGI isn't. But the ARC process is of necessity a somewhat heavyweight process (when it suits it- look at the automatic closed approved for the IOMMU case for the opposite). This means that people have to be fairly strongly motivated to do the right thing and use that process. Obvious changes and integrations that would make Solaris a developer's favorite didn't necessarily find a champion within Sun because it does and takes real work to think these things through. This does now seem to be changing, but there is perhaps more tension between ARC and getting things "into" Solaris (for some measure of "into") than still should be. From gdamore@sun.com Thu Nov 13 16:46:36 2008 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 mAE0kZMl010727 for ; Thu, 13 Nov 2008 16:46:36 -0800 (PST) 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 mAE0kK9h015681 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 08:46:27 +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 <0KAA0050BSTF8U00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:46:27 -0800 (PST) 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 <0KAA001LVSTEZ430@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:46:26 -0800 (PST) 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 mAE0kQiL020761 for ; Thu, 13 Nov 2008 16:46:26 -0800 (PST) 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 <0KAA00L01SN9U200@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 16:46:26 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA009DISTA4IB0@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 16:46:23 -0800 (PST) Date: Thu, 13 Nov 2008 16:40:54 -0800 From: "Garrett D'Amore" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC687.6060809@sun.com> Sender: Garrett.Damore@sun.com To: Matthew Jacob Cc: Nicolas Williams , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CC916.7010200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2409 Matthew Jacob wrote: > Nicolas Williams wrote: >> On Thu, Nov 13, 2008 at 04:04:43PM -0800, Matthew Jacob wrote: >> >>> It isn't just a debug aid. Similar tools and libraries dependent >>> upon those tools began shipping from Legato in 1994 because of lack >>> of support within Solaris. As far as I know, they still ship, >>> although they probably use sgen when available. >>> >>> This Legato thing isn't just a random user package. This is a major >>> backup package that Sun used to OEM. It still generated 500$M/yr >>> revenue for EMC. >>> >>> Repeated discussions with Sun over the years pointing out both >>> Legato's discomfort (*and* Sun's discomfort- at one point they were >>> even maintaining the tools I believe) over using raw access in this >>> way never really went anywhere. >>> >>> So please don't tell me I'm exaggerating. I know precisely whereof I >>> speak. >>> >> So I'm confused here. You've made some claims, which is that legato needed this kind of package. I'll take that for granted. But what I don't understand is *why*. I freely admit I don't have years of experience with SCSI. But I do work on device drivers for a living. I can't imagine a situation where I need a shell utility to perform actions on a bus, *except* when I'm doing debugging. And in those cases, honestly, I usually wind up either downloading something or using a custom written tool. (Usually the latter.) I *never* ship any of those bits (the test bits) to my customers, nor do I make my software depend on them. I have a hard time understanding why these kinds of low-level tools would be provided by a 3rd party ISV to users. So is the architectural gap here a failure to provide tools that legato needed to *develop* the software, or is it lack of building blocks to build their software? (And if the latter, why does it necessarily follow that CLI access is what is needed, as opposed to libscsi or the like?) Again, I'm just trying to understand the utility here to end users that justifies integrating this as a first class package (with RBAC and such) into Solaris. Why do ordinary end-users need this stuff? (Or even ordinary developers. I don't include developers for storage products because their needs are special, and I *suspect* they fall outside the target audience that the "familiarity" justification was intended for.) -- Garrett From Matthew.Jacob@sun.com Thu Nov 13 17:58:37 2008 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 mAE1war5013837 for ; Thu, 13 Nov 2008 17:58:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE1wVZt026304 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 01:58:35 GMT 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 <0KAA00209W5ME500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 18:58:34 -0700 (MST) 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 <0KAA00K78W5LN970@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 18:58:33 -0700 (MST) 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 mAE1wXm2025958 for ; Thu, 13 Nov 2008 17:58:33 -0800 (PST) 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 <0KAA00301W3WT500@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 17:58:33 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00MSTW5IES10@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 17:58:31 -0800 (PST) Date: Thu, 13 Nov 2008 17:57:21 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC916.7010200@sun.com> Sender: Matthew.Jacob@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CDB01.2060008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 4778 > > So I'm confused here. You've made some claims, which is that legato > needed this kind of package. I'll take that for granted. But what I > don't understand is *why*. Because Sun didn't either provide a changer driver or generic SCSI bus access. Even if Sun had provided a changer driver, generic SCSI bus access would have been preferable. There are always cases where the native feature set provided by a platform is less than the market needs, or is outright broken. It's not that Legato shipped command line tools that user could use- it incorporated them into internal libraries and provided a generic uscsi access. This was so it would write software once and use a generic uscsi interface across win32, AIX, Linux, IRIX, SunOS (yes, Solaris 1), Solaris and so on. > > I freely admit I don't have years of experience with SCSI. But I do > work on device drivers for a living. I can't imagine a situation > where I need a shell utility to perform actions on a bus, *except* > when I'm doing debugging. And in those cases, honestly, I usually > wind up either downloading something or using a custom written tool. > (Usually the latter.) > > I *never* ship any of those bits (the test bits) to my customers, nor > do I make my software depend on them. I have a hard time > understanding why these kinds of low-level tools would be provided by > a 3rd party ISV to users. That is one perspective on development. In principle, I agree with you. This is not entirely the reality on the ground now. Incorporation of command line tools to perform device functions, or subsuming the io control paths used by those functions into non-CLI type tools certainly is not a big surprise. I can easily see a case where I would ship a production package that would use something out of sg3_utils to collect information, parse it, and use it. If it's not part of a critical data path but is an important adjunct to, say, configuration, or FRU information gathering, I'd use it just like I'd use smartmontools. Why rewrite things when they work "well enough"? If someone (my boss in a startup) says "this function needs to be done next week" you can bet I'm not going to say "the product absolutely cannot work unless we do a formal design, document, review, prototype, etc.." if it's something straightforward like "run lsscsi and grep for device "FOO"". It's swell if you work for a company that allows you the luxury of doing traditional engineering. My experience with consulting over the last 15 or so years has indicated that this kind of approach is getting harder and harder to find. In fact, the whole reason I came back to Sun for the current gig was that doing so would afford me the time one rarely gets to try and do things correctly. I'm not arguing therefore that we shouldn't respect such practices and try and follow them. I'm just suggesting that the customer base for where a lot of this seems to be going has a much less restrictive set of expectations than you express, and has less patience with "we can't give you your favorite tool BAR because it doesn't meet *our* standards" than you can possibly imagine. > > Again, I'm just trying to understand the utility here to end users > that justifies integrating this as a first class package (with RBAC > and such) into Solaris. Why do ordinary end-users need this stuff? > (Or even ordinary developers. I don't include developers for storage > products because their needs are special, and I *suspect* they fall > outside the target audience that the "familiarity" justification was > intended for.) > > So it may not need to be a first class package. This is what I was groping for in other mail. You want to provide correctly engineered systems. But you also want to provide tools for developers who might not share your opinion about what is correctly engineered. Whether it's a first class package or not, having it there without requiring people to install it or dork with it is a win. End users who use this system for non-development purposes could care less about what packages are included or whether they're first, fifth or completely unsuipported- they just want it to work. But is this the target market? It's not like we are marketing decisions here, but if the game is to try and capture mindshare (again), then it's developers, not end-users, who need to be stroked, and a lot of these developers don't necessarily even understand the issues you talk about let alone agree with your take on them. Like I said, it's a balance that has to be struck, and from what I've seen over the years since I've been back is that, IMHO, the balance is still to much toward the classic Solaris SDF model. Again, IMHO. -matt From gdamore@sun.com Thu Nov 13 18:49:52 2008 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 mAE2nquO014811 for ; Thu, 13 Nov 2008 18:49:52 -0800 (PST) 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 mAE2nqZV000360 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 18:49:52 -0800 (PST) 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 <0KAA00M05YJ4BI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 18:49:52 -0800 (PST) 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 <0KAA00CN9YJ3RME0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 18:49:51 -0800 (PST) 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 mAE2npAb010634 for ; Thu, 13 Nov 2008 18:49:51 -0800 (PST) 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 <0KAA00E01YG9Q600@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 18:49:51 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA00M01YJ2ESD0@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 18:49:50 -0800 (PST) Date: Thu, 13 Nov 2008 18:44:22 -0800 From: "Garrett D'Amore" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CDB01.2060008@sun.com> Sender: Garrett.Damore@sun.com To: Matthew Jacob Cc: Nicolas Williams , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CE606.40903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 6132 So, with everything else you said, wouldn't it make more sense for these bits to live in /usr/lib (linux might be libexec), since they're not something intended for end-users to run from the command line? I confess I'm still unhappy with the justification here -- are the next programs going to be a bunch of utilities to toggle interrupt status registers on the CPU? Is it our goal to make it possible to write device drivers in shell script? (I know Roland would just *love* to write one in ksh93...) These days we have libscsi and friends. Application developers should be able to use those directly. Yeah, its not conducive to building enterprise grade software out of sh or perl code (though I confess I'd probably be less upset if this were delivered as a perl library... but I am not sure I can really justify why, apart from the fact that it makes clearer the target audience is for software development rather than for end-user consumption.) I know this isn't supposed to be a popularity contest, but are there any concrete examples of 3rd party applications built upon these bits? Is this case a solution looking for a problem? -- Garrett Matthew Jacob wrote: >> >> So I'm confused here. You've made some claims, which is that legato >> needed this kind of package. I'll take that for granted. But what I >> don't understand is *why*. > > Because Sun didn't either provide a changer driver or generic SCSI bus > access. > > Even if Sun had provided a changer driver, generic SCSI bus access > would have been preferable. There are always cases where the native > feature set provided by a platform is less than the market needs, or > is outright broken. > > It's not that Legato shipped command line tools that user could use- > it incorporated them into internal libraries and provided a generic > uscsi access. This was so it would write software once and use a > generic uscsi interface across win32, AIX, Linux, IRIX, SunOS (yes, > Solaris 1), Solaris and so on. >> >> I freely admit I don't have years of experience with SCSI. But I do >> work on device drivers for a living. I can't imagine a situation >> where I need a shell utility to perform actions on a bus, *except* >> when I'm doing debugging. And in those cases, honestly, I usually >> wind up either downloading something or using a custom written tool. >> (Usually the latter.) >> >> I *never* ship any of those bits (the test bits) to my customers, nor >> do I make my software depend on them. I have a hard time >> understanding why these kinds of low-level tools would be provided by >> a 3rd party ISV to users. > > That is one perspective on development. In principle, I agree with > you. This is not entirely the reality on the ground now. Incorporation > of command line tools to perform device functions, or subsuming the io > control paths used by those functions into non-CLI type tools > certainly is not a big surprise. > > I can easily see a case where I would ship a production package that > would use something out of sg3_utils to collect information, parse it, > and use it. If it's not part of a critical data path but is an > important adjunct to, say, configuration, or FRU information > gathering, I'd use it just like I'd use smartmontools. Why rewrite > things when they work "well enough"? If someone (my boss in a startup) > says "this function needs to be done next week" you can bet I'm not > going to say "the product absolutely cannot work unless we do a formal > design, document, review, prototype, etc.." if it's something > straightforward like "run lsscsi and grep for device "FOO"". > > It's swell if you work for a company that allows you the luxury of > doing traditional engineering. My experience with consulting over the > last 15 or so years has indicated that this kind of approach is > getting harder and harder to find. In fact, the whole reason I came > back to Sun for the current gig was that doing so would afford me the > time one rarely gets to try and do things correctly. > > I'm not arguing therefore that we shouldn't respect such practices and > try and follow them. I'm just suggesting that the customer base for > where a lot of this seems to be going has a much less restrictive set > of expectations than you express, and has less patience with "we can't > give you your favorite tool BAR because it doesn't meet *our* > standards" than you can possibly imagine. > > >> >> Again, I'm just trying to understand the utility here to end users >> that justifies integrating this as a first class package (with RBAC >> and such) into Solaris. Why do ordinary end-users need this stuff? >> (Or even ordinary developers. I don't include developers for storage >> products because their needs are special, and I *suspect* they fall >> outside the target audience that the "familiarity" justification was >> intended for.) >> >> > So it may not need to be a first class package. This is what I was > groping for in other mail. You want to provide correctly engineered > systems. But you also want to provide tools for developers who might > not share your opinion about what is correctly engineered. Whether > it's a first class package or not, having it there without requiring > people to install it or dork with it is a win. > > End users who use this system for non-development purposes could care > less about what packages are included or whether they're first, fifth > or completely unsuipported- they just want it to work. But is this the > target market? > > It's not like we are marketing decisions here, but if the game is to > try and capture mindshare (again), then it's developers, not > end-users, who need to be stroked, and a lot of these developers don't > necessarily even understand the issues you talk about let alone agree > with your take on them. > > > Like I said, it's a balance that has to be struck, and from what I've > seen over the years since I've been back is that, IMHO, the balance is > still to much toward the classic Solaris SDF model. Again, IMHO. > > -matt > From Matthew.Jacob@sun.com Thu Nov 13 20:34:52 2008 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 mAE4Ypck016878 for ; Thu, 13 Nov 2008 20:34:52 -0800 (PST) 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 mAE4YVLI014717 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 12:34:50 +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 <0KAB00B033E2F300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:34:50 -0800 (PST) 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 <0KAB0042X3E1TP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:34:50 -0800 (PST) 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 mAE4YnpH002292 for ; Thu, 13 Nov 2008 20:34:49 -0800 (PST) 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 <0KAB00E0136MG700@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:34:49 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAB000023E0BHF0@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 20:34:49 -0800 (PST) Date: Thu, 13 Nov 2008 20:33:36 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CE606.40903@sun.com> Sender: Matthew.Jacob@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <491CFFA0.6020700@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> <491CE606.40903@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 2086 Garrett D'Amore wrote: > So, with everything else you said, wouldn't it make more sense for > these bits to live in /usr/lib (linux might be libexec), since they're > not something intended for end-users to run from the command line? Which end-users? If the end-user is a developer, the bits should live in something describe in PATH. If the end-user isn't a developer, the bits shouldn't matter where they live because the non-developer won't be using them (unless they act as a pseudo-developer installing a scanner to their system, fervently wishing that they'd installed Leopard instead...). > > I confess I'm still unhappy with the justification here -- are the > next programs going to be a bunch of utilities to toggle interrupt > status registers on the CPU? Is it our goal to make it possible to > write device drivers in shell script? (I know Roland would just > *love* to write one in ksh93...) See the user-level driver package distributed by Microsoft for use on win2k, XP or Vista. *Microsoft* isn't worried that the end user will use it inappropriately, and they have a heck of a lot more exposure than anyone else to that kind of user. > > These days we have libscsi and friends. Application developers should > be able to use those directly. You're kidding, right? ultra20 > man libscsi No manual entry for libscsi. Looking at the case materials for 2008/196 (which, btw, is a painful process when going through opensolaris.org), libscsi, and libses, are built on top of sgen(7d). Jesus wept, this misses the points I've been trying to make. > > I know this isn't supposed to be a popularity contest, but are there > any concrete examples of 3rd party applications built upon these > bits? Is this case a solution looking for a problem? Sigh. That also misses the point. In a query to Mullholland in the '30s, someone asked "Does LA need this water?", whereupon Mullholand responded with "If LA does not get the water, LA won't need the water.". I think I should take myself off the ARC mailing list. I seem *so* out of step. -matt From James.McPherson@sun.com Thu Nov 13 20:41:18 2008 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 mAE4fIjf016991 for ; Thu, 13 Nov 2008 20:41:18 -0800 (PST) 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 mAE4fHwV002562 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Nov 2008 20:41:18 -0800 (PST) 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 <0KAB00C013OT7B00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:41:17 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB004D73OSTM30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 20:41:17 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAE4fFUj017968 for ; Fri, 14 Nov 2008 04:41:16 +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 <0KAB00A013KJH700@mail-apac.sun.com> (original mail from James.McPherson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Nov 2008 12:41:15 +0800 (SGT) Received: from blinder ([220.157.71.44]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KAB001X93OOGNLN@mail-apac.sun.com>; Fri, 14 Nov 2008 12:41:15 +0800 (SGT) Date: Fri, 14 Nov 2008 14:41:08 +1000 From: "James C. McPherson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CFFA0.6020700@sun.com> Sender: James.McPherson@sun.com To: Matthew Jacob Cc: "Garrett D'Amore" , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <20081114144108.00002d3f@blinder> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.3; i386-pc-solaris2.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> <491CE606.40903@sun.com> <491CFFA0.6020700@sun.com> Status: RO Content-Length: 1110 On Thu, 13 Nov 2008 20:33:36 -0800 Matthew Jacob wrote: > Garrett D'Amore wrote: ... > > These days we have libscsi and friends. Application developers > > should be able to use those directly. > > You're kidding, right? > > ultra20 > man libscsi > No manual entry for libscsi. > > Looking at the case materials for 2008/196 (which, btw, is a painful > process when going through opensolaris.org), libscsi, and libses, are > built on top of sgen(7d). Jesus wept, this misses the points I've > been trying to make. No, he's not kidding. This is pretty much the same question I asked last week. Just because there's no manpage doesn't mean that it's impossible to use - or don't people read source code any more? libses makes use of sgen(7d), but libscsi doesn't mandate use of libses. Pluggable fwflash(1m) uses both libscsi and libses, and the code for almost of it is open. What's your underlying objection to using libscsi and/or libses? James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog From Matthew.Jacob@sun.com Thu Nov 13 21:23:30 2008 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 mAE5NT9N018462 for ; Thu, 13 Nov 2008 21:23:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE5N60k012102 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 05:23:28 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAB00H015N3HF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 21:23:27 -0800 (PST) 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 <0KAB004T45N2TO50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 21:23:26 -0800 (PST) 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 mAE5NQZM003926 for ; Thu, 13 Nov 2008 21:23:26 -0800 (PST) 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 <0KAB00C015MGUW00@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 21:23:26 -0800 (PST) Received: from [192.168.1.3] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAB00H105N1P370@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 21:23:26 -0800 (PST) Date: Thu, 13 Nov 2008 21:22:13 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081114144108.00002d3f@blinder> Sender: Matthew.Jacob@sun.com To: "James C. McPherson" Cc: "Garrett D'Amore" , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <491D0B05.4020701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> <491CE606.40903@sun.com> <491CFFA0.6020700@sun.com> <20081114144108.00002d3f@blinder> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Status: RO Content-Length: 1819 > > No, he's not kidding. This is pretty much the same question > I asked last week. > > Just because there's no manpage doesn't mean that it's impossible > to use - or don't people read source code any more? > Of course one reads source code. It's called Intellectual Property Security through Obscurity (IPSO, for short, without any FACTO appended). I asked a very pertinent question last week while I was in Broomfield: "What constitutes DDI Compliance?". My take on this is a shell script I wrote in 1991 which looks for external symbols in a module and tries to find a man page. If it doesn't have a man page, it's not in the DDI. You could stretch that a bit and say "well, search the ARC materials" and if you find an adequate definition there, maybe you could say some interface was documented and an exportable "spec". The point here is that if we use things like the ARC and have an interface taxonomy, we should adequately document those interfaces. We don't have to write a developer's guide for everything, but something more than what is generally there. The libscsi case material and lack of documentation hardly constitutes a substitute. If it were backed up by 10 years of mailing list discussions like the linux "sg" driver is, that wouldn't be a problem, But it isn't. There's some cryptic blog entries, and some source code and > libses makes use of sgen(7d), but libscsi doesn't mandate use > of libses. > It's less than clear how you would implement it. > Pluggable fwflash(1m) uses both libscsi and libses, and the code > for almost of it is open. > > What's your underlying objection to using libscsi and/or libses? > > None, per se. They were referred to as a "now we have them, so all [developer/user usability] problerms are solved" reference. I beg to differ. From gdamore@sun.com Thu Nov 13 21:32:36 2008 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 mAE5WZXg018647 for ; Thu, 13 Nov 2008 21:32:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE5WU0k016496 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 05:32:34 GMT 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 <0KAB00J03628Y400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 22:32:32 -0700 (MST) 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 <0KAB00B6X6270QC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 22:32:31 -0700 (MST) 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 mAE5WVTN015218 for ; Thu, 13 Nov 2008 21:32:31 -0800 (PST) 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 <0KAB00G0160NCL00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Nov 2008 21:32:31 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAB00HHQ626P380@fe-sfbay-10.sun.com>; Thu, 13 Nov 2008 21:32:31 -0800 (PST) Date: Thu, 13 Nov 2008 21:27:00 -0800 From: "Garrett D'Amore" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081114144108.00002d3f@blinder> Sender: Garrett.Damore@sun.com To: "James C. McPherson" Cc: Matthew Jacob , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <491D0C24.6040709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> <491CE606.40903@sun.com> <491CFFA0.6020700@sun.com> <20081114144108.00002d3f@blinder> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3683 James C. McPherson wrote: > On Thu, 13 Nov 2008 20:33:36 -0800 > Matthew Jacob wrote: > > >> Garrett D'Amore wrote: >> > ... > >>> These days we have libscsi and friends. Application developers >>> should be able to use those directly. >>> >> You're kidding, right? >> >> ultra20 > man libscsi >> No manual entry for libscsi. >> >> Looking at the case materials for 2008/196 (which, btw, is a painful >> process when going through opensolaris.org), libscsi, and libses, are >> built on top of sgen(7d). Jesus wept, this misses the points I've >> been trying to make. >> > > > No, he's not kidding. This is pretty much the same question > I asked last week. > > Just because there's no manpage doesn't mean that it's impossible > to use - or don't people read source code any more? > > libses makes use of sgen(7d), but libscsi doesn't mandate use > of libses. > > Pluggable fwflash(1m) uses both libscsi and libses, and the code > for almost of it is open. > > What's your underlying objection to using libscsi and/or libses? > Right. (Although are those APIs public commitment? Maybe a better case would be to elevate their commitment level. I'm not sure.) And I think Matthew missed one more point, when he claimed that > Which end-users? If the end-user is a developer, the bits should live > in something describe in PATH. If the end-user isn't a developer, the > bits shouldn't matter where they live because the non-developer won't > be using them (unless they act as a pseudo-developer installing a > scanner to their system, fervently wishing that they'd installed > Leopard instead...). My point is that if the consumer here is layered software, rather than someone typing these commands on a command line, then they don't belong in the PATH. I still haven't got an answer about that. What is the target audience here? Do we expect ordinary folks to be typing these commands? (I'm not talking about someone manually using it to debug their application. We don't put /usr/lib/mixer_applet2 in /usr/sbin, although someone debugging audio might have cause to run it manually (I have done so!).. What I was talking about was whether folks would run this as a normal course of action during their work. (Developer or otherwise.) Example: snoop is useful for diagnostics, and while many people are blissfully ignorant of it, it is typically run on the command line. tcp wrappers, on the other hand, are normally not run by someone typing the name of the command.) The other question, which was ignored, is that if the intent here is that this is for use primarily as a building block for layered software, is there any layered software which exists that builds on it. I understand adding building blocks that we need, and even adding duplicates when there is demand for the specific duplicate. But if there is no demand, then frankly unless there is some other justification (like users want to type this at the command line), then I don't see a reason for us to be muddying the architectural waters by providing choices that aren't being asked for. I know, I know... I'm a bit crotchety because I still haven't been convinced that just because you *can* ship a piece of software it doesn't mean you *should*, despite the current trend of "integrate everything *and* the kitchen sink, useful or otherwise, into Solaris." I'm on sabbatical, so I'll shut up now... Although I'd still like to see answers to my fundamental questions, you're not obliged to answer them. You can consider my concerns as heckling coming from the peanut gallery if you prefer. -- Garrett From Nicolas.Williams@sun.com Thu Nov 13 21:54:55 2008 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 mAE5stGu020455 for ; Thu, 13 Nov 2008 21:54:55 -0800 (PST) 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 mAE5smwX009522; Thu, 13 Nov 2008 22:54:49 -0700 (MST) 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 <0KAB00K0573CMD00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 21:54:48 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB00I0Q73CQQ20@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Nov 2008 21:54:48 -0800 (PST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mAE5sA0n115498; Thu, 13 Nov 2008 23:54:10 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.14.3+Sun/8.14.3/Submit) id mAE5sAHw115497; Thu, 13 Nov 2008 23:54:10 -0600 (CST) Date: Thu, 13 Nov 2008 23:54:10 -0600 From: Nicolas Williams Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081114144108.00002d3f@blinder> To: "James C. McPherson" Cc: Matthew Jacob , "Garrett D'Amore" , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <20081114055409.GX111792@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> <491CDB01.2060008@sun.com> <491CE606.40903@sun.com> <491CFFA0.6020700@sun.com> <20081114144108.00002d3f@blinder> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1524 On Fri, Nov 14, 2008 at 02:41:08PM +1000, James C. McPherson wrote: > On Thu, 13 Nov 2008 20:33:36 -0800 > Matthew Jacob wrote: > > > These days we have libscsi and friends. Application developers > > > should be able to use those directly. > > > > You're kidding, right? > > > > ultra20 > man libscsi > > No manual entry for libscsi. > > > > Looking at the case materials for 2008/196 (which, btw, is a painful > > process when going through opensolaris.org), libscsi, and libses, are > > built on top of sgen(7d). Jesus wept, this misses the points I've > > been trying to make. > > > No, he's not kidding. This is pretty much the same question > I asked last week. > > Just because there's no manpage doesn't mean that it's impossible > to use - or don't people read source code any more? Sorry, but no. If there's no manpage it's most likely because it's not a public, stable interface. That means you'd need to either be in the same consolidation or have a contract in order to consume it, depending on the interface's actual stability attributes. So either Garret is wrong to suggest use of libscsi, or there's a doc bug (missing manpage), or someone had better promote the stability of libscsci and document it ASAP. IF sg3 cannot be stable on Solaris without using something like libscsi, then it's reasonable to suggest that it use libscsi, but I suspect the reality is the reverse (that until libscsi becomes stable the best thing to do is for sg3 to not use it). Nico -- From casper@holland.sun.com Fri Nov 14 00:50:22 2008 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 mAE8oMvs024312 for ; Fri, 14 Nov 2008 00:50:22 -0800 (PST) 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 mAE8oLj8011955; Fri, 14 Nov 2008 00:50:21 -0800 (PST) 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 <0KAB00I07F7XI600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 00:50:21 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB00DR1F7VXU30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 00:50:20 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE8o98s064048; Fri, 14 Nov 2008 08:50:09 +0000 (GMT) Date: Fri, 14 Nov 2008 09:50:09 +0100 From: Casper.Dik@sun.com Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CBB21.4020601@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: "Mark A. Carlson" , Bart Smaalders , James Carlson , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <200811140850.mAE8o98s064048@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> Status: RO Content-Length: 380 >So with that in mind, I think I agree with Jim. The folks using these >utilities should be smart enough to figure out to run the commands as >root, without needing preconfigured RBAC. Just because a user logs in >to the console, I don't think he should have access to the raw busses of >the console devices (including USB, SCSI, and any 8042 style busses.) > +1 Casper From casper@holland.sun.com Fri Nov 14 01:01:03 2008 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 mAE91324024790 for ; Fri, 14 Nov 2008 01:01:03 -0800 (PST) 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 mAE912LT018232; Fri, 14 Nov 2008 02:01:02 -0700 (MST) 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 <0KAB00J03FPPMU00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 01:01:01 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB00DTTFPOXU40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 01:01:01 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE90q5W001815; Fri, 14 Nov 2008 09:00:52 +0000 (GMT) Date: Fri, 14 Nov 2008 10:00:52 +0100 From: Casper.Dik@sun.com Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC916.7010200@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Matthew Jacob , Nicolas Williams , "Mark A. Carlson" , Bart Smaalders , James Carlson , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <200811140900.mAE90q5W001815@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> <491CC916.7010200@sun.com> Status: RO Content-Length: 358 >So I'm confused here. You've made some claims, which is that legato >needed this kind of package. I'll take that for granted. But what I >don't understand is *why*. I thought this was for tape robots? (With networking I find that it's installing stuff in sgen.conf and, for some reason, this breaks how my x4200 talks to the tape (DLT3).) Casper From Darren.Moffat@sun.com Fri Nov 14 04:15:15 2008 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 mAECFFqx029134 for ; Fri, 14 Nov 2008 04:15:15 -0800 (PST) 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 mAECFETb027280 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 14 Nov 2008 04:15:14 -0800 (PST) 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 <0KAB0030BOPEBD00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Nov 2008 05:15:14 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB00E1MOPD6FF0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Nov 2008 05:15:13 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAECFCZC022151 for ; Fri, 14 Nov 2008 12:15:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAB00L01OHKFL00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Nov 2008 12:15:12 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAB008C3OP26770@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 14 Nov 2008 12:15:04 +0000 (GMT) Date: Fri, 14 Nov 2008 12:15:02 +0000 From: Darren J Moffat Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <200811131903.mADJ3OQg016513@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Xiao.L@sun.com Cc: psarc-ext@sun.com Message-id: <491D6BC6.3030609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811131903.mADJ3OQg016513@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1544 It seems more effort has been put into arguing why not to do a simple RBAC profile for these command than it would have actually taken do it it. If the project team doesn't actually know what privilege the commands need to run then I'd say they architecture isn't ready for review. Just saying that they all might need to run with euid=0 isn't good enough in my opinion - particularly given how dangerous some of these commands can be. We aren't asking for anything really complex we aren't even asking for a single line of code change. Given that all of these commands need to actually be tested to work before integration all that needs to be done is work out what privileges they need when their functionality testing is being done. The ppriv command with -D should be enough here. I believe the project team has already done some if not all of this. On the other hand I think Jim and Casper may have a good point here that because these commands are so possibility dangerous we wouldn't actually want to hand them out to some one via an RBAC profile because what can be done with them could be essentially equivalent to handing out all privs and uid=0 anyway. If that is the case then I'll agree no RBAC profile for these is necessary - but might still be nice to have. I'm not going to hold up this cases any further. I'm getting to the point I think that ARC review is useless given all the push back we get from project teams about doing anything with respect to the ARC best practices. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Nov 14 05:45:40 2008 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 mAEDjdhU001442 for ; Fri, 14 Nov 2008 05:45:39 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAEDjS47001748; Fri, 14 Nov 2008 13:45:31 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAB00409SVTG300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 05:45:29 -0800 (PST) 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 <0KAB00A93SVSEE70@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 05:45:28 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAEDjR7O029308; Fri, 14 Nov 2008 08:45:27 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mAEDjQh4029305; Fri, 14 Nov 2008 08:45:26 -0500 (EST) Date: Fri, 14 Nov 2008 08:45:26 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <20081113235327.GS111792@Sun.COM> To: Nicolas Williams Cc: "Garrett D'Amore" , "Mark A. Carlson" , Bart Smaalders , Matthew Jacob , Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Gary Winiger Message-id: <18717.33014.929004.43395@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.4.1.325704 References: <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> Status: RO Content-Length: 848 Nicolas Williams writes: > On Thu, Nov 13, 2008 at 03:41:21PM -0800, Garrett D'Amore wrote: > > It seems *awfully* strange to me that we feel obliged to integrate a set > > of command line utilities which are designed to provide raw access to a > > hardware bus to the command line. > > I don't think that's trange at all. It's a useful debug aid at the very > least, and it may well be a useful integrator's tool for gluing things > together as well. It is strange when I'd expect to do this sort of hackery via "mdb -kw", and not by way of some odd /usr/sbin utility. What's next? /usr/sbin/peek and /usr/sbin/poke? -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Fri Nov 14 05:51:04 2008 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 mAEDp30u001735 for ; Fri, 14 Nov 2008 05:51:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAEDoqel004726; Fri, 14 Nov 2008 13:50:56 GMT 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 <0KAB00J0VT4V5100@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Nov 2008 05:50:55 -0800 (PST) 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 <0KAB00FI7T4UP360@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Nov 2008 05:50:54 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAEDoriC029335; Fri, 14 Nov 2008 08:50:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mAEDordD029332; Fri, 14 Nov 2008 08:50:53 -0500 (EST) Date: Fri, 14 Nov 2008 08:50:53 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC687.6060809@sun.com> To: Matthew Jacob Cc: Nicolas Williams , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , "Garrett D'Amore" , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <18717.33341.353073.867670@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.4.1.325704 References: <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB215.4040808@Sun.COM> <491CB563.3000503@sun.com> <491CBB21.4020601@sun.com> <20081113235327.GS111792@Sun.COM> <491CC09B.2040608@sun.com> <20081114001103.GU111792@Sun.COM> <491CC687.6060809@sun.com> Status: RO Content-Length: 1538 Matthew Jacob writes: > But the ARC process is of necessity a somewhat heavyweight process (when > it suits it- look at the automatic closed approved for the IOMMU case > for the opposite). This means that people have to be fairly strongly > motivated to do the right thing and use that process. Obvious changes > and integrations that would make Solaris a developer's favorite didn't > necessarily find a champion within Sun because it does and takes real > work to think these things through. This does now seem to be changing, > but there is perhaps more tension between ARC and getting things "into" > Solaris (for some measure of "into") than still should be. That seems silly. I fear C-teams and the general wrath of my fellow developers for having broken something much more than I do any open review in the ARC. If "obvious" integrations aren't happening because the ARC is too "heavy," then I think that's actually a symptom of a different set of linked problems: we've got too many system-wide features in Solaris that are (a) implemented differently from other operating systems (aka "innovative") and (b) not supported by much existing open source software. There's a price to pay for being different, and this is it. Those aren't problems we can wave a wand to remove or just wish away. -- James Carlson, Solaris Networking Sun Microsystems / 35 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 Fri Nov 14 06:35:15 2008 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 mAEEZE3W003158 for ; Fri, 14 Nov 2008 06:35:15 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAEEZ4Ld001426; Fri, 14 Nov 2008 14:35:08 GMT 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 <0KAB00H0LV6JSV00@brm-avmta-1.central.sun.com>; Fri, 14 Nov 2008 07:35:07 -0700 (MST) 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 <0KAB008DWV6HJ7E0@brm-avmta-1.central.sun.com>; Fri, 14 Nov 2008 07:35:05 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAEEZ4bU029495; Fri, 14 Nov 2008 09:35:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mAEEZ4H7029492; Fri, 14 Nov 2008 09:35:04 -0500 (EST) Date: Fri, 14 Nov 2008 09:35:04 -0500 From: James Carlson Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CB4B0.4020606@sun.com> To: Matthew Jacob Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <18717.35992.418807.729112@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.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB4B0.4020606@sun.com> Status: RO Content-Length: 2290 Matthew Jacob writes: > + Is it worth including at all? > + Is it worth including even incomplete wrt RBAC? > + Is it worth including if it takes a year to sort out RBAC and other > issues? I think you might be assuming that we'll see this project team again and that they'll improve things. No offense intended towards the project team, but history teaches us otherwise: we either get all of our issues out on the table and dealt with in some manner, or we forever hold our piece. Once they integrate, project teams tend to fall under a bus. (For that matter, the same holds true for design, code, and C-team reviews.) So, add to that list: + Is it worthwhile giving ARC approval to an incomplete project when there's no demonstrable commitment to improving things later? (And I'd give the length of this email thread as pretty good evidence of a lack of commitment.) > it anyway. Perhaps another thing to make the inclusion of these packages > easier is a "optional but unsupported because...." category which is > just a documentation exercise. Like, we could say "sg3_utils is > something you can add, but it doesn't meet the Solaris criteria of a, b, > c which is why it's not part of the default release. You have been warned". That's basically what /opt/sfw (Companion CD) used to be. Just compile, toss it in, and hope it sticks. It wasn't exactly a popular solution -- in part because we're not known for being particularly spry in fetching new sources and recompiling, even the process barrier is reduced effectively to zero. We've had our run of experiments with software ghettos, and it doesn't seem to end well, so I'd suggest not going there again. We know how the story ends. Since you seem to be leaning on the Linux side of things, I think the best answer might be the earlier suggestion I made (and seconded by Garrett, Casper, and Darren, though we haven't heard from Gary) to avoid an RBAC profile entirely and let the user play "invent an architecture" with it. Document what privileges are needed, and wish them luck. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From kmcdonald@egenera.com Fri Nov 14 07:06:04 2008 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 mAEF63fd003732 for ; Fri, 14 Nov 2008 07:06:03 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAEF5rIa021268; Fri, 14 Nov 2008 15:05:55 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAB00C13WLTLQ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 07:05:53 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAB00AZJWLPELA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 14 Nov 2008 07:05:49 -0800 (PST) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAEF5mYt008179; Fri, 14 Nov 2008 15:05:49 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-652422; Fri, 14 Nov 2008 15:05:48 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-3123043; Fri, 14 Nov 2008 15:05:47 +0000 (Z) Received: from webaccess.egenera.com ([63.139.209.15] [63.139.209.15]) by relay4i.sun.com with ESMTP id BT-MMP-12711888; Fri, 14 Nov 2008 15:05:47 +0000 (Z) Received: from [172.23.2.112] ([172.23.2.112]) by webaccess.egenera.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Nov 2008 10:05:47 -0500 Date: Fri, 14 Nov 2008 10:04:28 -0500 From: Kyle McDonald Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491CC916.7010200@sun.com> To: "Garrett D'Amore" Cc: Matthew Jacob , Xiao.L@sun.com, "Mark A. Carlson" , Gary Winiger , James Carlson , Richard.Matthews@sun.com, PSARC-ext@sun.com, Bart Smaalders Message-id: <491D937C.7030404@Egenera.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.235sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <491CC916.7010200@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) X-OriginalArrivalTime: 14 Nov 2008 15:05:47.0087 (UTC) FILETIME=[79369DF0:01C9466A] Status: RO Content-Length: 2311 Garrett D'Amore wrote: > > > So I'm confused here. You've made some claims, which is that legato > needed this kind of package. I'll take that for granted. But what I > don't understand is *why*. > This was many years ago but... With Legato (and NetBackup I beleive,) I remember running one command (sgscan maybe?) not often, but as a regular part of a Backup server setup. That was the command that from the command line performed the same function as 'probe-scsi-all' does from OBP. it was useful for determining which SCSI id's you needed to configure the tool to use for the library. You ran it, more than once usually. You verified the devices seen were what you expected, you took notes on device ID's, then ran the install tool for the package and entered in the info you had taken down. I had been looking for this type of functionality in solaris for years before, and I did end up using the tool that vame with the backup packages for my own purposes once i knew they were there. These packages also had library control utilities to script library operations which I had also looked for in the past when considering scripting my own backups myself, but I didn't need that as much once I bought these packages. Other than scanning the the bus to report what devices were present and where though, I can't remember wanting for any other SCSI tools I didn't already have. That's not to say that I wouldn't love what some of these other tools do. I 'm probably just not up to speed on what a tool could let me do. > Again, I'm just trying to understand the utility here to end users that > justifies integrating this as a first class package (with RBAC and such) > into Solaris. Why do ordinary end-users need this stuff? (Or even > ordinary developers. I don't include developers for storage products > because their needs are special, and I *suspect* they fall outside the > target audience that the "familiarity" justification was intended for.) > As someone said though, I always knew and understood that I'd need to be root (or have equivalent privs today - that was pre-RBAC if I recall correctly.) to run such a tool. -Kyle > -- Garrett > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From Matthew.Jacob@sun.com Fri Nov 14 07:32:29 2008 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 mAEFWSOK003913 for ; Fri, 14 Nov 2008 07:32:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAEFWQJc010297 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Nov 2008 15:32:27 GMT 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 <0KAB0000DXU1X800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Nov 2008 08:32:25 -0700 (MST) 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 <0KAB00IVKXU0QY30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Nov 2008 08:32:24 -0700 (MST) 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 mAEFWOaN021378 for ; Fri, 14 Nov 2008 07:32:24 -0800 (PST) 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 <0KAB00F01XOHE400@fe-sfbay-10.sun.com> (original mail from Matthew.Jacob@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Nov 2008 07:32:24 -0800 (PST) Received: from [192.168.1.2] ([72.164.148.65]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAB00FJAXTV0110@fe-sfbay-10.sun.com>; Fri, 14 Nov 2008 07:32:20 -0800 (PST) Date: Fri, 14 Nov 2008 07:32:11 -0800 From: Matthew Jacob Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <18717.35992.418807.729112@gargle.gargle.HOWL> Sender: Matthew.Jacob@sun.com To: James Carlson Cc: Richard.Matthews@sun.com, Darren J Moffat , PSARC-ext@sun.com, Xiao.L@sun.com, Mark.Carlson@sun.com, Gary Winiger Message-id: <491D99FB.10201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811132007.mADK7M21020636@marduk.eng.sun.com> <491C8BCA.4000201@Sun.COM> <491CA0F5.60307@Sun.COM> <18716.41841.512213.106363@gargle.gargle.HOWL> <491CA6E3.7090005@sun.com> <18716.43628.921.782776@gargle.gargle.HOWL> <491CAC07.8090808@sun.com> <18716.44915.553221.835523@gargle.gargle.HOWL> <491CB4B0.4020606@sun.com> <18717.35992.418807.729112@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.18) Gecko/20081031 SeaMonkey/1.1.13 Status: RO Content-Length: 383 > > > Since you seem to be leaning on the Linux side of things, I think the > best answer might be the earlier suggestion I made (and seconded by > Garrett, Casper, and Darren, though we haven't heard from Gary) to > avoid an RBAC profile entirely and let the user play "invent an > architecture" with it. Document what privileges are needed, and wish > them luck. > > D'accord. From Xiao.L@sun.com Tue Nov 18 17:47:10 2008 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 mAJ1l97o016757 for ; Tue, 18 Nov 2008 17:47:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAJ1l4JD011373 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Nov 2008 01:47:08 GMT 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 <0KAK0000V4YIZ700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Nov 2008 17:47:06 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAK00MS34YF5F20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Nov 2008 17:47:04 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAJ1l3x0022263 for ; Wed, 19 Nov 2008 01:47:03 +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 <0KAK00K014XZ2O00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Nov 2008 09:47:03 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KAK0046K4YC3RB0@mail-apac.sun.com>; Wed, 19 Nov 2008 09:47:03 +0800 (SGT) Date: Wed, 19 Nov 2008 09:49:14 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <491BFA01.9090106@Sun.COM> Sender: Xiao.L@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com Message-id: <4923709A.2080906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <491BCBF4.3060007@sun.com> <491BFA01.9090106@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 4160 Hi Darren, I've worked out my draft version of two new profiles as you suggested. Please see below for details: [usr/src/lib/libsecdb/prof_attr] SCSI Device Info:::Inquiry, read device information:help=RtSCSIDevInfo.html SCSI Device Management:::Manage, modify device status or data:profiles=SCSI Device Info;help=RtSCSIDevMngmnt.html [usr/src/lib/libsecdb/exec_attr] SCSI Device Info:solaris:cmd:::/usr/bin/sg_get_config:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_ident:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_inq:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_logs:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_luns:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_modes:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_opcodes:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_read_buffer:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_read_long:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_readcap:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_requests:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_rmsn:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_rtpg:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_safte:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_sat_identify:euid=0;privs=sys_devices SCSI Device Info:solaris:cmd:::/usr/bin/sg_vpd:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_sync:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_persist:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_prevent:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_raw:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_rdac:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_reassign:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_sat_set_features:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_senddiag:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_ses:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_start:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_stpg:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_sync:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_turs:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_verify:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_wr_mode:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_write_buffer:euid=0;privs=sys_devices SCSI Device Management:solaris:cmd:::/usr/bin/sg_write_long:euid=0;privs=sys_devices Comments are welcome. Thanks a lot and best regards, -Xiao Darren J Moffat wrote: > xiao li - Sun Microsystems - Beijing China wrote: >> The "System Administrator" is not a user, it's one of the existing >> rights profiles, we could grant it to any user or role as we want. >> These commands are by design for system administration, I think we >> should put them under the rights profile "File System Management" >> which is a supplementary rights profile of "System Administrator". >> So it will depend on the customers which user/role would run these >> commands, not restricted to superuser(root). > > Since this has NOTHING to do with "File Systems" I don't think that is > an appropriate existing RBAC profile. > > I would like to see one or maybe two new profiles: > > "SCSI Device Info" Contains the non empty set of commands from this > case that require privilege but are non destructive in all their modes > of operation - ie they are "status/info" commands only. > > "SCSI Device Management" Contains all of "SCSI Device Info" (as an > included profile if possible) plus any commands from this case that > have a destructive or change capability. > > From Kais.Belgaied@sun.com Wed Nov 19 11:10:49 2008 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 mAJJAmqI013698 for ; Wed, 19 Nov 2008 11:10:49 -0800 (PST) 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 mAJJAhwH035268; Wed, 19 Nov 2008 12:10:45 -0700 (MST) 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 <0KAL00J01H9WON00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Nov 2008 11:10:44 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAL00I09H9V3A20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Nov 2008 11:10:44 -0800 (PST) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAJJAhUa935018; Wed, 19 Nov 2008 11:10:43 -0800 (PST) Date: Wed, 19 Nov 2008 11:10:43 -0800 From: Kais Belgaied Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <4923709A.2080906@sun.com> To: xiao li - Sun Microsystems - Beijing China Cc: Darren J Moffat , Gary Winiger , PSARC-ext@sun.com Reply-to: Kais.Belgaied@sun.com Message-id: <492464B3.8050309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <491BCBF4.3060007@sun.com> <491BFA01.9090106@Sun.COM> <4923709A.2080906@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 239 Given the non obviousness of the choices made here, and the thought process that went in converging to the changes added to the case, this case is derailed. Mark accepted to prepare the draft opinion to be submitted for vote. Kais. From gww@sac.sfbay.sun.com Wed Nov 19 14:59:22 2008 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 mAJMxLgi021355 for ; Wed, 19 Nov 2008 14:59:21 -0800 (PST) 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 mAJMxI0d009839 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 06:59:20 +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 <0KAL0030TRUTL700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Nov 2008 14:59:17 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAL00BI1RUS7270@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Nov 2008 14:59:16 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAJMx6nN030913; Wed, 19 Nov 2008 14:59:06 -0800 (PST) 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 mAJMx6N2021352; Wed, 19 Nov 2008 14:59:06 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mAJMx6Mb021351; Wed, 19 Nov 2008 14:59:06 -0800 (PST) Date: Wed, 19 Nov 2008 14:59:06 -0800 (PST) From: Gary Winiger Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] To: Kais.Belgaied@sun.com, Xiao.L@sun.com Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2705 Kais writes: > Given the non obviousness of the choices made here, and the thought > process that went in converging to the changes added to the > case, this case is derailed. > > Mark accepted to prepare the draft opinion to be submitted for vote. Presumably the draft opinion will answer the set of questions the project team has not yet answered: Such as why is sys_devices required to run the view commands? Why are the modes restricted? What is the policy? Why is the policy appropriate? What, if any, Rights Profiles are appropriate? Since the claim is required privileges, what about limitprivs? Perhaps after understanding the why of the device policy, the view routines may not need any special rights at all. OR Jim writes: > That's basically what /opt/sfw (Companion CD) used to be. Just > compile, toss it in, and hope it sticks. It wasn't exactly a popular > solution -- in part because we're not known for being particularly > spry in fetching new sources and recompiling, even the process barrier > is reduced effectively to zero. > > We've had our run of experiments with software ghettos, and it doesn't > seem to end well, so I'd suggest not going there again. We know how > the story ends. Do we resurrect the software ghetto as some way of saying stuff isn't really integrated into Solaris, but just there as a download convenience. > Since you seem to be leaning on the Linux side of things, I think the > best answer might be the earlier suggestion I made (and seconded by > Garrett, Casper, and Darren, though we haven't heard from Gary) to > avoid an RBAC profile entirely and let the user play "invent an > architecture" with it. Document what privileges are needed, and wish > them luck. I'm not sure this isn't back to the logical equivalent of the companion CD, or how I use versiontracker.com. The OpenSolaris Cabinet seems to be throwing around the concepts of various classes of repositories ranging from it complies therefore it must be perfect - figure out how to use and use at your own risk - to business critical and fully integrated with Solaris Policies and Practices. What seems to be missing from the review process is the vocabulary / winnowing fork for such a review. Do we expect the draft opinion to provide that. Since I was asked directly about this case: if it falls in the "it compiles therefore it must be prefect - figure out how to use and ...." bucket, I'm happy with the suggestion summarized in Jim's mail. If, however it falls East of there, there is insufficient information in the case without answers to the set of questions posed above for me to understand how integrated sg3 "should be." Gary.. From Xiao.L@Sun.COM Wed Nov 19 16:01:13 2008 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 mAK01DPg024348 for ; Wed, 19 Nov 2008 16:01:13 -0800 (PST) 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 mAK015vw010981 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Nov 2008 16:01:13 -0800 (PST) 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 <0KAL00M07UPZP200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Nov 2008 17:01:11 -0700 (MST) 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 <0KAL0024RUPX01B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Nov 2008 17:01:10 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mAK019cH002861 for ; Thu, 20 Nov 2008 00:01:09 +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 <0KAL00E01UMV4S00@mail-apac.sun.com> (original mail from Xiao.L@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 08:01:09 +0800 (SGT) Received: from [129.158.144.215] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KAL00286UPV96I0@mail-apac.sun.com>; Thu, 20 Nov 2008 08:01:09 +0800 (SGT) Date: Thu, 20 Nov 2008 08:03:20 +0800 From: xiao li - Sun Microsystems - Beijing China Subject: [Fwd: Re: sg3 utilities 1.25 [PSARC/2008/683]] Sender: Xiao.L@Sun.COM To: Gary Winiger Cc: PSARC-ext@Sun.COM Message-id: <4924A948.1060203@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_c1Cs+ADYhp48VyLVGtk+fA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 8854 This is a multi-part message in MIME format. --Boundary_(ID_c1Cs+ADYhp48VyLVGtk+fA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT FYI, -------- Original Message -------- Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] Date: Sat, 15 Nov 2008 11:13:46 +0800 From: Xiao Li To: Gary Winiger CC: Darren.Moffat@Sun.COM References: <200811150126.mAF1QuBe023325@marduk.eng.sun.com> Hi Gary, Thanks for your response, please see my comments below. Gary Winiger wrote: >> Hi Darren and Gary, >> If you're both ok with these two new profiles, could I post it to PSARC-ext? >> > > Please answer the questions that you have avoided answering: > From the most recent time I asked them: > > Such as why is sys_devices required to run the view commands? > These commands are utilizing USCSICMD interface to send scsi command, and this interface need the process have the privilege of sys_devices. It will call drv_priv() to check the privilege no matter the process is reading or writing to the device file. > And why are the modes restricted? Sorry, I do not quite understand this question. > What is the policy? Why > is the policy appropriate? I'm using the policy "solaris", according to the manpage of exec_attr. Is this what you are asking? > And as you say why File System Management? > It is included in System Administrator, so why is that the > appropriate set of Rights Profiles for these commands? > I've worked out two new profiles "SCSI Device Info" and "SCSI Device Management" as suggested by Darren. > Since the claim is required privileges, what about limitprivs? > limitprivs=all. > Perhaps after understanding the why of the device policy, > the view routines may not need any Rights Profile at all. > From (one of the Xiao Li's) email that showed > crw-r----- 1 root sys > sgid sys might be appropriate. > Without the project team explaination of rationale for the > existant policy, I can't judge. > > And explain the rationale for the existant policy. Only then > is it possible to review the Rights Profiles. > The original source code is opening the device file with flag O_RDWR, so euid=0 is necessary, but I've tried if I set it to O_RDONLY, it will work as well, and just egid=sys is enough. However as I mentioned above, sys_devices is needed when sending USCSI command, this is by design of Solaris. -Xiao > If you can't answer the questions and explain the existant policy, > contact your case owner for directions on how to proceed. > > Gary.. > --Boundary_(ID_c1Cs+ADYhp48VyLVGtk+fA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT FYI,

-------- Original Message --------
Subject: Re: sg3 utilities 1.25 [PSARC/2008/683]
Date: Sat, 15 Nov 2008 11:13:46 +0800
From: Xiao Li <xiao.l@sun.com>
To: Gary Winiger <gww@eng.sun.com>
CC: Darren.Moffat@Sun.COM
References: <200811150126.mAF1QuBe023325@marduk.eng.sun.com>


Hi Gary,
Thanks for your response, please see my comments below.

Gary Winiger wrote: 
Hi Darren and Gary,
If you're both ok with these two new profiles, could I post it to PSARC-ext?
    

	Please answer the questions that you have avoided answering:
	From the most recent time I asked them:

	Such as why is sys_devices required to run the view commands?
                     These commands are utilizing USCSICMD interface to send scsi command, and this interface need
                      the process have the privilege of sys_devices. It will call drv_priv() to check the privilege no matter
                      the process is reading or writing to the device file.

	And why are the modes restricted?
                   Sorry, I do not quite understand this question.
What is the policy?  Why
	is the policy appropriate?
                   I'm using the policy "solaris", according to the manpage of exec_attr. Is this what you
                   are asking?
And as you say why File System Management?
	It is included in System Administrator, so why is that the
	appropriate set of Rights Profiles for these commands?
                   I've worked out two new profiles "SCSI Device Info" and "SCSI Device Management"
                   as suggested by Darren.
	Since the claim is required privileges, what about limitprivs?
                   limitprivs=all.
	Perhaps after understanding the why of the device policy,
	the view routines may not need any Rights Profile at all.
	From (one of the Xiao Li's) email that showed
	crw-r-----   1 root     sys 
	sgid sys might be appropriate.
	Without the project team explaination of rationale for the
	existant policy, I can't judge.

	And explain the rationale for the existant policy.  Only then
	is it possible to review the Rights Profiles.
                    The original source code is opening the device file with flag O_RDWR, so euid=0 is
                    necessary, but I've tried if I set it to O_RDONLY, it will work as well, and just
                    egid=sys is enough. However as I mentioned above, sys_devices is needed when
                    sending USCSI command, this is by design of Solaris.
-Xiao
	If you can't answer the questions and explain the existant policy,
	contact your case owner for directions on how to proceed.

Gary..
--Boundary_(ID_c1Cs+ADYhp48VyLVGtk+fA)-- From Darren.Moffat@sun.com Thu Nov 20 01:51:21 2008 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 mAK9pKHY013329 for ; Thu, 20 Nov 2008 01:51:20 -0800 (PST) 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 mAK9pHIa019661 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Nov 2008 02:51:20 -0700 (MST) 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 <0KAM0041FM1J3700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 01:51:19 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAM004ZWM1GMRC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 01:51:17 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAK9pFQJ006142 for ; Thu, 20 Nov 2008 09:51:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAM00B01LWFPN00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Nov 2008 09:51:15 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAM00KEVM0NBE20@fe-emea-09.sun.com>; Thu, 20 Nov 2008 09:50:50 +0000 (GMT) Date: Thu, 20 Nov 2008 09:50:47 +0000 From: Darren J Moffat Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Kais.Belgaied@sun.com, Xiao.L@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <492532F7.1060508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 908 Gary Winiger wrote: > Kais writes: >> Given the non obviousness of the choices made here, and the thought >> process that went in converging to the changes added to the >> case, this case is derailed. >> >> Mark accepted to prepare the draft opinion to be submitted for vote. > > Presumably the draft opinion will answer the set of questions > the project team has not yet answered: > > Such as why is sys_devices required to run the view commands? > Why are the modes restricted? Assuming you mean the modes of the device files the answer to this should be obvious. This project does not deliver the devices nor does it set the access policy for them. It just uses already existing devices on the system it is them that has set their file permission modes and them that require sys_devices even for "view commands". I believe the project team did attempt to answer that. -- Darren J Moffat From Mark.Carlson@sun.com Wed Dec 3 09:30:41 2008 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 mB3HUetF004734 for ; Wed, 3 Dec 2008 09:30:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3HUSKl017783 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 17:30:39 GMT 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 <0KBB00I2B9Z2LT00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:30:38 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBB0062Z9Z01E90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:30:36 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB3HUaUA025661 for ; Wed, 03 Dec 2008 17:30:36 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBB002018BVWX00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:30:12 -0700 (MST) Received: from dhcp-ubrm03-175-153.Central.Sun.COM ([129.147.175.153]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBB00FAM9Y7SDD0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:30:07 -0700 (MST) Date: Wed, 03 Dec 2008 10:30:06 -0700 From: "Mark A. Carlson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <492532F7.1060508@Sun.COM> Sender: Mark.Carlson@sun.com To: PSARC-ext@sun.com Cc: Xiao.L@sun.com Message-id: <4936C21E.9070105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> <492532F7.1060508@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) Status: RO Content-Length: 117 There is a draft opinion in the case directory. Please review for a possible business vote today. Thanks, -- mark From Mark.Carlson@Sun.COM Wed Dec 3 10:36:06 2008 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 mB3Ia5rh016871 for ; Wed, 3 Dec 2008 10:36:05 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3Ia4iB008141 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Dec 2008 18:36:04 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBB00D1LD027R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:36:02 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBB007I4D00PQ50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 10:36:00 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB3IZxqv001354 for ; Wed, 03 Dec 2008 18:35:59 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBB00201CU2HM00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 11:35:54 -0700 (MST) Received: from dhcp-ubrm03-175-153.Central.Sun.COM ([129.147.175.153]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBB00KOXCZS03H0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Dec 2008 11:35:52 -0700 (MST) Date: Wed, 03 Dec 2008 11:35:51 -0700 From: "Mark A. Carlson" Subject: Re: sg3 utilities 1.25 [PSARC/2008/683] In-reply-to: <4936C21E.9070105@sun.com> Sender: Mark.Carlson@Sun.COM To: PSARC-ext@Sun.COM Cc: Xiao.L@Sun.COM Message-id: <4936D187.90307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> <492532F7.1060508@Sun.COM> <4936C21E.9070105@sun.com> User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) Status: RO Content-Length: 319 This case was approved at PSARC today. -- mark Mark A. Carlson wrote: > There is a draft opinion in the case directory. Please review for a > possible business vote today. > > Thanks, > > -- mark > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From Mark.Carlson@sun.com Wed Dec 17 13:41:09 2008 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 mBHLf8Wd002066 for ; Wed, 17 Dec 2008 13:41:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBHLf0xO005353 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Dec 2008 21:41:07 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC100E1DIWJV600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Dec 2008 13:41:07 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC1008HEIWH5D50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Dec 2008 13:41:06 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBHLf5RI023497 for ; Wed, 17 Dec 2008 21:41:05 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC100501I0H6P00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Dec 2008 14:41:05 -0700 (MST) Received: from Macintosh-252.local ([129.150.34.110]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC100M2DIW7SXD0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Dec 2008 14:40:56 -0700 (MST) Date: Wed, 17 Dec 2008 14:40:55 -0700 From: "Mark A. Carlson" Subject: sg3 utilities 1.25 [PSARC/2008/683] updated, auto-approve In-reply-to: <4936D187.90307@sun.com> Sender: Mark.Carlson@sun.com To: PSARC-ext@sun.com Cc: Xiao.L@sun.com Message-id: <494971E7.1070008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200811192259.mAJMx6Mb021351@sac.sfbay.sun.com> <492532F7.1060508@Sun.COM> <4936C21E.9070105@sun.com> <4936D187.90307@sun.com> User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) Status: RO Content-Length: 27356 In process of integrating this case, the project team has had to modify the interface. If anyone wants me to restart a timer on this, let me know. -- mark The changes include: 1) The project needs to touch /etc/security/prof_attr and /etc/security/exec_attr, so they have divided the package into SUNWsg3utilsu -- The sg3 utilities (usr) SUNWsg3utilsr -- The sg3 utilities (root) 2) After more testing on the RBAC profiles, they found that they need to add two more privileges file_dac_read and file_dac_write in. 3) The manpage location should be /usr/share/man/man1m as suggested by ARC members instead of /usr/share/man/man1. The differences are as follows: --- sg3utils-fasttrack.txt.old Wed Dec 17 15:12:31 2008 +++ sg3utils-fasttrack.txt Wed Dec 17 19:02:51 2008 @@ -103,7 +103,8 @@ Exported interface Classification Interface type =============================== ============== ============== - SUNWsg3utils Uncommitted Package name + SUNWsg3utilsu Uncommitted Package name + SUNWsg3utilsr Uncommitted Package name /usr/sbin/sg_get_config Uncommitted Command /usr/sbin/sg_ident Uncommitted Command /usr/sbin/sg_inq Uncommitted Command @@ -139,40 +140,40 @@ /usr/lib/libsgutils.so Private Symbolic link /usr/lib/libsgutils.so.1 Private Symbolic link /usr/lib/libsgutils.so.1.0.0 Private Shared library file - /usr/share/man/man1/sg_read_long.1 Uncommitted Manpage - /usr/share/man/man1/sg_safte.1 Uncommitted Manpage - /usr/share/man/man1/sg_senddiag.1 Uncommitted Manpage - /usr/share/man/man1/sg_wr_mode.1 Uncommitted Manpage - /usr/share/man/man1/sg_stpg.1 Uncommitted Manpage - /usr/share/man/man1/sg_persist.1 Uncommitted Manpage - /usr/share/man/man1/sg_ses.1 Uncommitted Manpage - /usr/share/man/man1/sg_opcodes.1 Uncommitted Manpage - /usr/share/man/man1/sg_get_config.1 Uncommitted Manpage - /usr/share/man/man1/sg_read_buffer.1 Uncommitted Manpage - /usr/share/man/man1/sg_luns.1 Uncommitted Manpage - /usr/share/man/man1/sg_requests.1 Uncommitted Manpage - /usr/share/man/man1/sg_prevent.1 Uncommitted Manpage - /usr/share/man/man1/sg_rdac.1 Uncommitted Manpage - /usr/share/man/man1/sg_rtpg.1 Uncommitted Manpage - /usr/share/man/man1/sg_sat_identify.1 Uncommitted Manpage - /usr/share/man/man1/sg_start.1 Uncommitted Manpage - /usr/share/man/man1/sg_verify.1 Uncommitted Manpage - /usr/share/man/man1/sg_modes.1 Uncommitted Manpage - /usr/share/man/man1/sg_readcap.1 Uncommitted Manpage - /usr/share/man/man1/sg_sat_set_features.1 Uncommitted Manpage - /usr/share/man/man1/sg_rmsn.1 Uncommitted Manpage - /usr/share/man/man1/sg3_utils.1 Uncommitted Manpage - /usr/share/man/man1/sg_ident.1 Uncommitted Manpage - /usr/share/man/man1/sg_vpd.1 Uncommitted Manpage - /usr/share/man/man1/sg_inq.1 Uncommitted Manpage - /usr/share/man/man1/sg_raw.1 Uncommitted Manpage - /usr/share/man/man1/sg_turs.1 Uncommitted Manpage - /usr/share/man/man1/sg_sync.1 Uncommitted Manpage - /usr/share/man/man1/sg_logs.1 Uncommitted Manpage - /usr/share/man/man1/sg_format.1 Uncommitted Manpage - /usr/share/man/man1/sg_reassign.1 Uncommitted Manpage - /usr/share/man/man1/sg_write_long.1 Uncommitted Manpage - /usr/share/man/man1/sg_write_buffer.1 Uncommitted Manpage + /usr/share/man/man1m/sg_read_long.1m Uncommitted Manpage + /usr/share/man/man1m/sg_safte.1m Uncommitted Manpage + /usr/share/man/man1m/sg_senddiag.1m Uncommitted Manpage + /usr/share/man/man1m/sg_wr_mode.1m Uncommitted Manpage + /usr/share/man/man1m/sg_stpg.1m Uncommitted Manpage + /usr/share/man/man1m/sg_persist.1m Uncommitted Manpage + /usr/share/man/man1m/sg_ses.1m Uncommitted Manpage + /usr/share/man/man1m/sg_opcodes.1m Uncommitted Manpage + /usr/share/man/man1m/sg_get_config.1m Uncommitted Manpage + /usr/share/man/man1m/sg_read_buffer.1m Uncommitted Manpage + /usr/share/man/man1m/sg_luns.1m Uncommitted Manpage + /usr/share/man/man1m/sg_requests.1m Uncommitted Manpage + /usr/share/man/man1m/sg_prevent.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rdac.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rtpg.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sat_identify.1m Uncommitted Manpage + /usr/share/man/man1m/sg_start.1m Uncommitted Manpage + /usr/share/man/man1m/sg_verify.1m Uncommitted Manpage + /usr/share/man/man1m/sg_modes.1m Uncommitted Manpage + /usr/share/man/man1m/sg_readcap.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sat_set_features.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rmsn.1m Uncommitted Manpage + /usr/share/man/man1m/sg3_utils.1m Uncommitted Manpage + /usr/share/man/man1m/sg_ident.1m Uncommitted Manpage + /usr/share/man/man1m/sg_vpd.1m Uncommitted Manpage + /usr/share/man/man1m/sg_inq.1m Uncommitted Manpage + /usr/share/man/man1m/sg_raw.1m Uncommitted Manpage + /usr/share/man/man1m/sg_turs.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sync.1m Uncommitted Manpage + /usr/share/man/man1m/sg_logs.1m Uncommitted Manpage + /usr/share/man/man1m/sg_format.1m Uncommitted Manpage + /usr/share/man/man1m/sg_reassign.1m Uncommitted Manpage + /usr/share/man/man1m/sg_write_long.1m Uncommitted Manpage + /usr/share/man/man1m/sg_write_buffer.1m Uncommitted Manpage The following additional installed files are not interface. --- sg3utils-indiana-checklist.txt.old Wed Dec 17 15:12:36 2008 +++ sg3utils-indiana-checklist.txt Wed Dec 17 15:25:09 2008 @@ -59,8 +59,8 @@ [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? - [ ] Yes - [x] No or N/A + [x] Yes + [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below @@ -332,7 +332,8 @@ Interface Name Classification Comments --------------------------- ------------------- --------------------------- - SUNWsg3utils Uncommitted Package name + SUNWsg3utilsu Uncommitted Package name + SUNWsg3utilsr Uncommitted Package name /usr/sbin/sg_get_config Uncommitted Command /usr/sbin/sg_ident Uncommitted Command /usr/sbin/sg_inq Uncommitted Command @@ -368,43 +369,45 @@ /usr/lib/libsgutils.so Private Symbolic link /usr/lib/libsgutils.so.1 Private Symbolic link /usr/lib/libsgutils.so.1.0.0 Private Shared library file - /usr/share/man/man1/sg_read_long.1 Uncommitted Manpage - /usr/share/man/man1/sg_safte.1 Uncommitted Manpage - /usr/share/man/man1/sg_senddiag.1 Uncommitted Manpage - /usr/share/man/man1/sg_wr_mode.1 Uncommitted Manpage - /usr/share/man/man1/sg_stpg.1 Uncommitted Manpage - /usr/share/man/man1/sg_persist.1 Uncommitted Manpage - /usr/share/man/man1/sg_ses.1 Uncommitted Manpage - /usr/share/man/man1/sg_opcodes.1 Uncommitted Manpage - /usr/share/man/man1/sg_get_config.1 Uncommitted Manpage - /usr/share/man/man1/sg_read_buffer.1 Uncommitted Manpage - /usr/share/man/man1/sg_luns.1 Uncommitted Manpage - /usr/share/man/man1/sg_requests.1 Uncommitted Manpage - /usr/share/man/man1/sg_prevent.1 Uncommitted Manpage - /usr/share/man/man1/sg_rdac.1 Uncommitted Manpage - /usr/share/man/man1/sg_rtpg.1 Uncommitted Manpage - /usr/share/man/man1/sg_sat_identify.1 Uncommitted Manpage - /usr/share/man/man1/sg_start.1 Uncommitted Manpage - /usr/share/man/man1/sg_verify.1 Uncommitted Manpage - /usr/share/man/man1/sg_modes.1 Uncommitted Manpage - /usr/share/man/man1/sg_readcap.1 Uncommitted Manpage - /usr/share/man/man1/sg_sat_set_features.1 Uncommitted Manpage - /usr/share/man/man1/sg_rmsn.1 Uncommitted Manpage - /usr/share/man/man1/sg3_utils.1 Uncommitted Manpage - /usr/share/man/man1/sg_ident.1 Uncommitted Manpage - /usr/share/man/man1/sg_vpd.1 Uncommitted Manpage - /usr/share/man/man1/sg_inq.1 Uncommitted Manpage - /usr/share/man/man1/sg_raw.1 Uncommitted Manpage - /usr/share/man/man1/sg_turs.1 Uncommitted Manpage - /usr/share/man/man1/sg_sync.1 Uncommitted Manpage - /usr/share/man/man1/sg_logs.1 Uncommitted Manpage - /usr/share/man/man1/sg_format.1 Uncommitted Manpage - /usr/share/man/man1/sg_reassign.1 Uncommitted Manpage - /usr/share/man/man1/sg_write_long.1 Uncommitted Manpage - /usr/share/man/man1/sg_write_buffer.1 Uncommitted Manpage + /usr/share/man/man1m/sg_read_long.1m Uncommitted Manpage + /usr/share/man/man1m/sg_safte.1m Uncommitted Manpage + /usr/share/man/man1m/sg_senddiag.1m Uncommitted Manpage + /usr/share/man/man1m/sg_wr_mode.1m Uncommitted Manpage + /usr/share/man/man1m/sg_stpg.1m Uncommitted Manpage + /usr/share/man/man1m/sg_persist.1m Uncommitted Manpage + /usr/share/man/man1m/sg_ses.1m Uncommitted Manpage + /usr/share/man/man1m/sg_opcodes.1m Uncommitted Manpage + /usr/share/man/man1m/sg_get_config.1m Uncommitted Manpage + /usr/share/man/man1m/sg_read_buffer.1m Uncommitted Manpage + /usr/share/man/man1m/sg_luns.1m Uncommitted Manpage + /usr/share/man/man1m/sg_requests.1m Uncommitted Manpage + /usr/share/man/man1m/sg_prevent.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rdac.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rtpg.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sat_identify.1m Uncommitted Manpage + /usr/share/man/man1m/sg_start.1m Uncommitted Manpage + /usr/share/man/man1m/sg_verify.1m Uncommitted Manpage + /usr/share/man/man1m/sg_modes.1m Uncommitted Manpage + /usr/share/man/man1m/sg_readcap.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sat_set_features.1m Uncommitted Manpage + /usr/share/man/man1m/sg_rmsn.1m Uncommitted Manpage + /usr/share/man/man1m/sg3_utils.1m Uncommitted Manpage + /usr/share/man/man1m/sg_ident.1m Uncommitted Manpage + /usr/share/man/man1m/sg_vpd.1m Uncommitted Manpage + /usr/share/man/man1m/sg_inq.1m Uncommitted Manpage + /usr/share/man/man1m/sg_raw.1m Uncommitted Manpage + /usr/share/man/man1m/sg_turs.1m Uncommitted Manpage + /usr/share/man/man1m/sg_sync.1m Uncommitted Manpage + /usr/share/man/man1m/sg_logs.1m Uncommitted Manpage + /usr/share/man/man1m/sg_format.1m Uncommitted Manpage + /usr/share/man/man1m/sg_reassign.1m Uncommitted Manpage + /usr/share/man/man1m/sg_write_long.1m Uncommitted Manpage + /usr/share/man/man1m/sg_write_buffer.1m Uncommitted Manpage 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- + USCSICMD Committed PSARC 1997/288 + (originally Evolving) Appendix B - Suggested case materials 1. man pages --- sg3utils-opinion.txt.old Tue Dec 16 16:12:34 2008 +++ sg3utils-opinion.txt Wed Dec 17 18:58:52 2008 @@ -44,6 +44,10 @@ |__________________________________________|______________|_____________| |Interface |Classification|Comments | |__________________________________________|______________|_____________| +|SUNWsg3utilsr |Uncommitted |Package Name | +|__________________________________________|______________|_____________| +|SUNWsg3utilsu |Uncommitted |Package Name | +|__________________________________________|______________|_____________| |/usr/sbin/sg_get_config |Uncommitted |Command | |__________________________________________|______________|_____________| |/usr/sbin/sg_ident |Uncommitted |Command | @@ -115,73 +119,74 @@ |/usr/lib/libsgutils.so.1.0.0 |Private |Shared | | | |Library File | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_read_long.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_read_long.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_safte.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_safte.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_senddiag.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_senddiag.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_wr_mode.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_wr_mode.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_stpg.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_stpg.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_persist.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_persist.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_ses.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_ses.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_opcodes.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_opcodes.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_get_config.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_get_config.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_read_buffer.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_read_buffer.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_luns.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_luns.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_requests.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_requests.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_prevent.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_prevent.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_rdac.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_rdac.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_rtpg.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_rtpg.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_sat_identify.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_sat_identify.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_start.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_start.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_verify.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_verify.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_modes.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_modes.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_readcap.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_readcap.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_sat_set_features.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/ |Uncommitted |Manpage | +|sg_sat_set_features.1m | | | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_rmsn.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_rmsn.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg3_utils.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg3_utils.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_ident.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_ident.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_vpd.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_vpd.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_inq.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_inq.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_raw.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_raw.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_turs.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_turs.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_sync.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_sync.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_logs.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_logs.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_format.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_format.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_reassign.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_reassign.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_write_long.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_write_long.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| -|/usr/share/man/man1/sg_write_buffer.1 |Uncommitted |Manpage | +|/usr/share/man/man1m/sg_write_buffer.1m |Uncommitted |Manpage | |__________________________________________|______________|_____________| The project imports the following interfaces. @@ -244,40 +249,40 @@ SCSI Device Management:::Manage, modify device status or data:profiles=SCSI Device Info;help=RtSCSIDevMngmnt.html [usr/src/lib/libsecdb/exec_attr] -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_get_config:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_ident:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_inq:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_logs:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_luns:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_modes:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_opcodes:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_read_buffer:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_read_long:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_readcap:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_requests:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_rmsn:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_rtpg:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_safte:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_sat_identify:euid=0;privs=sys_devices -SCSI Device Info:solaris:cmd:::/usr/sbin/sg_vpd:euid=0;privs=sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_get_config:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_ident:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_inq:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_logs:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_luns:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_modes:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_opcodes:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_read_buffer:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_read_long:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_readcap:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_requests:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_rmsn:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_rtpg:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_safte:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_sat_identify:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Info:solaris:cmd:::/usr/sbin/sg_vpd:euid=0;privs=file_dac_read,file_dac_write,sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sync:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_persist:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_prevent:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_raw:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_rdac:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_reassign:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sat_set_features:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_senddiag:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_ses:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_start:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_stpg:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sync:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_turs:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_verify:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_wr_mode:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_write_buffer:euid=0;privs=sys_devices -SCSI Device Management:solaris:cmd:::/usr/sbin/sg_write_long:euid=0;privs=sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sync:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_persist:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_prevent:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_raw:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_rdac:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_reassign:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sat_set_features:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_senddiag:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_ses:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_start:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_stpg:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_sync:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_turs:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_verify:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_wr_mode:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_write_buffer:euid=0;privs=file_dac_read,file_dac_write,sys_devices +SCSI Device Management:solaris:cmd:::/usr/sbin/sg_write_long:euid=0;privs=file_dac_read,file_dac_write,sys_devices 7.3. Appendix C: Reference Material