From gww@sac.sfbay.sun.com Mon Dec 22 14:41: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 mBMMfhCb024305 for ; Mon, 22 Dec 2008 14:41: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 mBMMfbmg028921; Tue, 23 Dec 2008 06:41: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 <0KCA00M07V1F8L00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Dec 2008 14:41:39 -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 <0KCA00IUMV1FFI50@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Dec 2008 14:41:39 -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 mBMMfcip044035; Mon, 22 Dec 2008 14:41:38 -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 mBMMfb8x024300; Mon, 22 Dec 2008 14:41:37 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mBMMfbKp024296; Mon, 22 Dec 2008 14:41:37 -0800 (PST) Date: Mon, 22 Dec 2008 14:41:37 -0800 (PST) From: Gary Winiger Subject: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] To: PSARC-ext@sun.com Cc: audit-core@sun.com, sharon.read@sun.com Message-id: <200812222241.mBMMfbKp024296@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3251 I'm sponsoring this fast track for myself and the Solaris Audit project team. I've batched together a number of changes that could be handled independently, but seemed to largely fit together. If members would like them separated, I'll be happy to do so. The request is for an obsolescence announcement in a Patch release for potential removal in a Minor release. Details can be found below. For convenience full diff-marked man page are in the case directory. Due to the Sun Holiday schedule I've set the timer for 9 January 2009. Happy Holidays, Gary.. ================================================================================ Background: ++++++++++ For some time, the term BSM (Basic Security Module), which was introduced some time around SunOS 5.2 as a stubs and functional library named libbsm to meet the "C2" Audit and removal media object reuse requirements in Solaris, has been deprecated in the administrative documentation. Solaris Audit and Device Allocation have replaced the acronym BSM (the Bugster category "c2_bsm" is also being renamed to "audit"). Some of the interfaces covered by this case were neither originally ARCed nor assigned formal Interface Taxonomies, some have been updated from time to time and may have been ARCed and given taxonomies. This case assumes they are all come form of Stable. The project team assumes Evolving (now Committed). Proposal: ++++++++ * Change the Interface Taxonomies of bsmconv(1M), bsmunconv(1M), audit_startup(1M), audit_control(4), bsmrecord(1M) to Obsolete Committed (Obsolete Uncommitted in the case of bsmrecord) in a Patch release of Solaris. * Add a paragraph to the man page NOTES section: This command/file is Obsolete and may be removed and replaced with equivalent functionality in a future release of Solaris. * Add an announcement in the "What's New in the Solaris Release" document: In a future release, the commands for enabling/disabling Solaris Audit and Device Allocation, bsmconv(1M)/bsmunconv(1M), may be removed and replaced with equivalent functionality. In a future release, the command for displaying the Solaris Audit Record format, bsmrecord(1M), may be removed and replaced with equivalent functionality. In a future release, the command for configuring Solaris Audit Policies, audit_startup(1M), may be removed and replaced with equivalent functionality. In a future release, the configuration file for controlling the audit service -- auditd(1M), audit_control(4), may be removed and replaced with equivalent functionality. The intent is to move all the functionality of bsmconv/bsmunconv, audit_startup, and audit_control into the SMF service svc:/system/auditd (auditd(1M)) and the various other Solaris Audit and Device Allocation interfaces. At the time those changes come for Architectural Review they will be accompanied by a request for removal and transition plan. Additional Proposal: +++++++++++++++++++ This case also requests approval for the removal/replacement of bsmrecord(1M) in a Minor release. bsmrecord(1M) is to be replaced with auditrecord(1M). This consists renaming of the existing bsmrecord source, binary and man page and replacing docs references. From Darren.Moffat@sun.com Mon Dec 22 16:37:42 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 mBN0bgZ4013030 for ; Mon, 22 Dec 2008 16:37:42 -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 mBN0bf5n004309; Mon, 22 Dec 2008 16:37:41 -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 <0KCB00L070ETKO00@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Dec 2008 16:37: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 <0KCB007KG0ERMTD0@nwk-avmta-2.sfbay.sun.com>; Mon, 22 Dec 2008 16:37:40 -0800 (PST) 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 mBN0bdAi021193; Tue, 23 Dec 2008 00:37:39 +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 <0KCB00M010EQGN00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 23 Dec 2008 00:37:39 +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 <0KCB00FXP0EO8A60@fe-emea-09.sun.com>; Tue, 23 Dec 2008 00:37:39 +0000 (GMT) Date: Tue, 23 Dec 2008 00:37:36 +0000 From: Darren J Moffat Subject: Re: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] In-reply-to: <200812222241.mBMMfbKp024296@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, audit-core@sun.com, Sharon.Read@sun.com Message-id: <495032D0.1030709@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: <200812222241.mBMMfbKp024296@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 3 +1 From carlsonj@phorcys.east.sun.com Tue Dec 23 08:26:41 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 mBNGQfuk005524 for ; Tue, 23 Dec 2008 08:26:41 -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 mBNGQdlL048780; Tue, 23 Dec 2008 09:26:40 -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 <0KCC004118CFS600@brm-avmta-1.central.sun.com>; Tue, 23 Dec 2008 09:26:39 -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 <0KCC00HEX8CF55C0@brm-avmta-1.central.sun.com>; Tue, 23 Dec 2008 09:26:39 -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 mBNGQc9G018901; Tue, 23 Dec 2008 11:26:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBNGQcB9018898; Tue, 23 Dec 2008 11:26:38 -0500 (EST) Date: Tue, 23 Dec 2008 11:26:38 -0500 From: James Carlson Subject: Re: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] In-reply-to: <200812222241.mBMMfbKp024296@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, audit-core@sun.com, Sharon.Read@sun.com Message-id: <18769.4414.323542.922148@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: <200812222241.mBMMfbKp024296@sac.sfbay.sun.com> Status: RO Content-Length: 1166 Gary Winiger writes: > I'm sponsoring this fast track for myself and the Solaris Audit project > team. I've batched together a number of changes that could be handled > independently, but seemed to largely fit together. If members would > like them separated, I'll be happy to do so. I think this would have been better with more bundling (including the actual removal and transition plan), but I guess you can't please everyone. > This case also requests approval for the removal/replacement of bsmrecord(1M) > in a Minor release. bsmrecord(1M) is to be replaced with auditrecord(1M). > This consists renaming of the existing bsmrecord source, binary and man page > and replacing docs references. Would anyone be using bsmrecord in a script? Reading through the man page, it seems like it was intended to be used as a CGI program. If so, would a link to the old name be appropriate so that existing consumers don't break on removal? -- 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@sac.sfbay.sun.com Tue Dec 23 15:16:29 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 mBNNGSjJ028575 for ; Tue, 23 Dec 2008 15:16:29 -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 mBNNF3TV009578; Wed, 24 Dec 2008 07:16:27 +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 <0KCC00M01RBC8000@brm-avmta-1.central.sun.com>; Tue, 23 Dec 2008 16:16:24 -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 <0KCC009AERBB2U80@brm-avmta-1.central.sun.com>; Tue, 23 Dec 2008 16:16:24 -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 mBNNGMVd047112; Tue, 23 Dec 2008 15:16: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 mBNNGMWa028573; Tue, 23 Dec 2008 15:16:22 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mBNNGMIB028572; Tue, 23 Dec 2008 15:16:22 -0800 (PST) Date: Tue, 23 Dec 2008 15:16:22 -0800 (PST) From: Gary Winiger Subject: Re: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] To: gww@sac.sfbay.sun.com, james.d.carlson@sun.com Cc: PSARC-ext@sun.com, Sharon.Read@sun.com, audit-core@sun.com Message-id: <200812232316.mBNNGMIB028572@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2598 Jim, > Gary Winiger writes: > > I'm sponsoring this fast track for myself and the Solaris Audit project > > team. I've batched together a number of changes that could be handled > > independently, but seemed to largely fit together. If members would > > like them separated, I'll be happy to do so. > > I think this would have been better with more bundling (including the > actual removal and transition plan), but I guess you can't please > everyone. I'm assuming you're not asking me to separate this into a number of cases for the announcement, but are asking if the announcement and removal could be bundled into the same case(s). Sigh, except for renaming bsmrecord, they're not ready yet. The project team is trying to get EOF announcement stuff done early in the next Solaris update cycle. The thrust of all the changes is to have all the auditd service configuration reside in smf properties, to enable and disable Audit via svcadm, to configure properties with svccfg or auditconfig, with no more editing of /etc/security files. Without knowing how upgrade from S10 to OpenSolaris is intended to function, the project team is still working out details. It would be a great help to the project team if the committee could point the team to guidance for upgrade from S10 to OpenSolaris. It's unclear to the project team where and whether Major or Minor Release Binding rules are to be applied. I don't believe this case is about creating that guidance. > > This case also requests approval for the removal/replacement of bsmrecord(1M) > > in a Minor release. bsmrecord(1M) is to be replaced with auditrecord(1M). > > This consists renaming of the existing bsmrecord source, binary and man page > > and replacing docs references. > > Would anyone be using bsmrecord in a script? Reading through the man > page, it seems like it was intended to be used as a CGI program. If > so, would a link to the old name be appropriate so that existing > consumers don't break on removal? In the project team's experience bsmrecord is not widely used. Its purpose is to document the contents of audit records so docs.sun.com wouldn't require changing for every new event added to the system. bsmrecord is usually used interactively by the admin when analyzing the audit trail. Someone certainly could have built a web tool that used it. Leaving a symlink is certainly doable, but defeats the purpose of getting rid of administrative interfaces with "bsm" in them. Again committee guidance of Major/Minor Release Binding rules would be appreciated. Gary.. From carlsonj@phorcys.east.sun.com Wed Dec 24 05:31: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 mBODVLnu020243 for ; Wed, 24 Dec 2008 05:31:22 -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 mBODV5YB022157; Wed, 24 Dec 2008 21:31:19 +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 <0KCD00805UW4GC00@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Dec 2008 05:31:16 -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 <0KCD005FQUW38Y50@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Dec 2008 05:31:16 -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 mBODVEUT021438; Wed, 24 Dec 2008 08:31:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBODVEgT021435; Wed, 24 Dec 2008 08:31:14 -0500 (EST) Date: Wed, 24 Dec 2008 08:31:14 -0500 From: James Carlson Subject: Re: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] In-reply-to: <200812232316.mBNNGMIB028572@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, Sharon.Read@sun.com, audit-core@sun.com Message-id: <18770.14754.472619.474370@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: <200812232316.mBNNGMIB028572@sac.sfbay.sun.com> Status: RO Content-Length: 4275 Gary Winiger writes: > I'm assuming you're not asking me to separate this into a number > of cases for the announcement, but are asking if the announcement > and removal could be bundled into the same case(s). Right, and only for clarity. I don't think it's necessary. > The thrust of all the changes is to have all the auditd service > configuration reside in smf properties, to enable and disable > Audit via svcadm, to configure properties with svccfg or auditconfig, > with no more editing of /etc/security files. Sounds good. > Without knowing how upgrade from S10 to OpenSolaris is intended > to function, the project team is still working out details. It > would be a great help to the project team if the committee could > point the team to guidance for upgrade from S10 to OpenSolaris. > It's unclear to the project team where and whether Major or Minor > Release Binding rules are to be applied. Sigh. This is a big problem, and this isn't the only project affected by it. I don't think anybody knows the particulars around upgrade (or even whether upgrade will ever be supported), or exactly what release binding the OpenSolaris distribution has (or even if it has "releases" as we know them at all). I wish we could provide that sort of guidance. In order to do it, we'd have to have more details on what OpenSolaris *is* and how it is intended to work. We don't have those details (gang of four issue?), so we're just haphazardly applying guesses based on what we've done in the past. > I don't believe this case is about creating that guidance. I wouldn't think so, either. > > > This case also requests approval for the removal/replacement of bsmrecord(1M) > > > in a Minor release. bsmrecord(1M) is to be replaced with auditrecord(1M). > > > This consists renaming of the existing bsmrecord source, binary and man page > > > and replacing docs references. > > > > Would anyone be using bsmrecord in a script? Reading through the man > > page, it seems like it was intended to be used as a CGI program. If > > so, would a link to the old name be appropriate so that existing > > consumers don't break on removal? > > In the project team's experience bsmrecord is not widely used. > Its purpose is to document the contents of audit records so > docs.sun.com wouldn't require changing for every new event > added to the system. bsmrecord is usually used interactively > by the admin when analyzing the audit trail. Someone certainly > could have built a web tool that used it. Leaving a symlink > is certainly doable, but defeats the purpose of getting rid of > administrative interfaces with "bsm" in them. Again committee > guidance of Major/Minor Release Binding rules would be appreciated. I suggest the link at least because the "-h" option produces HTML, and I can't see how that'd be terribly useful outside of some sort of scripted environment -- either a CGI script or something that generates batches of files for browser inspection. I detest seeing HTML goop in email messages; I can't imagine what sort of infarction I'd suffer if I got it from an interactive command as well. ;-} I certainly don't mind if the obscure letters "bsm" disappear from all of the documentation, or if the command appears under a new name, or if the source code changes, or if the error messages it produces use a new name, but I don't think that the directory contents of /usr/sbin is itself a form of documentation, so I don't think leaving behind a link is a harmful thing for the renaming project, and it would avoid direct incompatibilities -- regardless of whether OpenSolaris has a Major or Minor release binding. As best I understand it, Major release (if that's what we indeed have) means that we "can" have incompatibilities where we need to. It doesn't mean that we "should." If the argument is just that nobody uses it, so there's no point in providing any compatibility, then as long as the project team has done the due diligence here and checked for users, I'm happy; nuke 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 gww@sac.sfbay.sun.com Wed Jan 7 11:32:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n07JWS8m018563 for ; Wed, 7 Jan 2009 11:32:29 -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 n07JWBUd050069; Wed, 7 Jan 2009 12:32:28 -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 <0KD400I538Y39P00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 07 Jan 2009 11:32:27 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KD400I3C8Y09700@nwk-avmta-1.sfbay.Sun.COM>; Wed, 07 Jan 2009 11:32:24 -0800 (PST) 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 n07JWOwB028484; Wed, 07 Jan 2009 11:32: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 n07JWNap018561; Wed, 07 Jan 2009 11:32:23 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n07JWN43018560; Wed, 07 Jan 2009 11:32:23 -0800 (PST) Date: Wed, 07 Jan 2009 11:32:23 -0800 (PST) From: Gary Winiger Subject: Re: Obsolete of some Solaris Audit commands [PSARC/2008/787 FastTrack timeout 01/09/2009] To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com Cc: audit-core@sun.com, sharon.read@sun.com Message-id: <200901071932.n07JWN43018560@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 424 > Due to the Sun Holiday schedule I've set the timer for 9 January 2009. This case was approved at today's PSARC meeting. The project team will investigate whether a symlink for auditrecord to bsmrecord in the case that the investigation turns out that there are significant scripts that embed bsmrecord -h, a symlink will be left behind, otherwise no symlink will be part of the name change. Happy New Year, Gary.. From sacadmin Tue May 5 16:33:26 2009 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45NXPMV012647 for ; Tue, 5 May 2009 16:33:25 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n45NWVIk020073; Tue, 5 May 2009 16:32:31 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n45NWVxj020072; Tue, 5 May 2009 16:32:31 -0700 (PDT) Date: Tue, 5 May 2009 16:32:31 -0700 (PDT) From: Gary Winiger Message-Id: <200905052332.n45NWVxj020072@marduk.eng.sun.com> To: psarc-record@sac.sfbay.sun.com Subject: PSARC/2008/787 follow up on bsmrecord symlink Cc: john.zolnowsky@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 2163 As part of the integration review process, it was pointed out that the project team didn't follow up to the case on the results of the symlink investigation. The project team investigated by using a google search for "bsmrecord" and turned up no meaningful references outside of references to the Solaris/OpenSolaris man page or source code. The project team send the following mail to those within Sun related to the audit project - this includes fork from the various organizations including service - and to the greater Sun security community that includes a number of folk with direct customer contact and information. The project team received on replies of any customer dependency that would require a symlink. In fact there were no replies at all to the issue. The replies were about other parts of the audit subsystem. Gary.. ====== From gww Thu Jan 8 18:06:16 2009 To: audit-core@sun.com, security-interest@sun.com Subject: Help with customer use of bsmrecord Bcc: gww X-Sun-Charset: US-ASCII Content-Length: 1113 X-Lines: 23 Status: O As part of the Audit Project Teams changes for Solaris Next, bsmrecord(1m) is being renamed auditrecord(1m). See PSARC/2008/787 Obsolete of some Solaris Audit commands Part of the motivation is to continue the obsolescence of the acronym BSM (Basic Security Module) which today is really just Solaris Audit (Bugster category "c2_bsm" is being renamed "audit" as well). In general auditrecord(1m) is used interactively by an audit administrator to understand the contents of a particular audit record. However, the -h option generates HTML formated output. It seems that this would only be consumed as part of some webserver (cgi) scripts. The Audit Project team prefers not to leave behind a compatibility symlink and to just rename /usr/sbin/bsmrecord to /usr/sbin/auditrecord. Rather than turn such a preference into a call generator for Solaris Next, I'm sending this to y'all to get any feedback on the customer impact you might expect. If this is seen as an abuse of this mailing list, please privately suggest a more appropriate place to take this query. Thanks in advance for your comments, Gary..