From sacadmin Fri Dec 21 17:02:33 2007 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 lBM12XAE000891; Fri, 21 Dec 2007 17:02:33 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lBM12XHE000887; Fri, 21 Dec 2007 17:02:33 -0800 (PST) Date: Fri, 21 Dec 2007 17:02:33 -0800 (PST) From: Gary Winiger Message-Id: <200712220102.lBM12XHE000887@sac.sfbay.sun.com> To: psarc-ext@sun.com Cc: paul.m.roberts@sun.com Subject: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] Status: RO Content-Length: 5574 I'm sponsoring this case for Paul Roberts and the Audit Project team. It incompatibly modifies the Evolving auditconfig(1M) and Committed auditon(2) interfaces to reflect the present implementation. It requests a Patch release binding and permission to remove the non-functioning interfaces in a patch even if the replacement functionality is not present in the same Patch. Full diff marked man pages are in the case directory along with the excellent One Pager written by Paul. The one pager goes into details of how an open customer escalation is waiting to be close based on Sun's declaration of these interfaces Obsolete. See 6185615 audit context file statistics are no longer getting updated correctly It is possible that the escalating customer may not require a patch be generated, but just Sun's intent to obsolete these interfaces in Solaris. The timer is set for 9 Jan. 2008. Happy Holidays, Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: ========== PSARC/2002/150 Secure Remote Audit Log, changed the implementation of writing data to the audit file from I/O done within the kernel to a userland plugin for that audit service svc:/system/auditd. This change took place in S10. PSARC/2002/665 Audit Interface Reclassification addressed some of the the obsolescences that went along with this implementation change. (VIZ., both auditsvc(2) and audit_data(4) were declared obsolete and permitted for removal in the next minor release, i.e., S11). Unfortunately, both cases failed to observe that the S9 and preceding implementation had two features that were not implemented in S10. auditconfig -setfsize sets a kernel value that used to be interpreted as a limit on the number of bytes in any audit file to at which time that file would be closed an a new file opened automatically (similar to what an administrator can do manually with the audit(1M) -n command). auditconfig -getfsize reports the size set by -setfsize and the number of bytes currently written to the active audit file. Proposal: ======== Declare auditconfig(1M) -[gs]etfsize Evolving interfaces obsolete immediately and allow them to be remove in an upcoming patch release. There is a slight chance that a customer may have modified the audit_startup(1M) script[1] to include -setfsize, or might have a script or cron job that includes -getfsize. A suitable "What's New" will call this out. Declare the auditon(2) Committed implementation of these functions obsolete immediately and allow them to be remove in an upcoming patch release. There is a very remote chance that a customer may have written a program that calls the auditon(2) implementation of these functions. Add a new parameter, p_fsize, to audit_binfile(5), the auditd plugin that implements writing to the local audit file, to replace the functionality of -setfsize. No replacement for -getfsize is proposed. The administrator can always ls -l the *not-terminated* audit file to observe its size. Details: ======= auditconfig(1M): +++++++++++++++ OPTIONS - -getfsize - Return the maximum audit file size in bytes and the - current size of the audit file in bytes. - -setfsize size - Set the maximum size of an audit file to size bytes. - - When the size limit is reached, the audit file is closed - and another is started. - - If perzone is not set, this option is valid only in the - global zone. NOTES + The -getfsize and -setfsize options have been removed. Use + audit_binfile(5) p_fsize to set the file size. audit_binfile(5): +++++++++++++++++ OBJECT ATTRIBUTES + The p_fsize attribute defines the maximum size in bytes that + an audit file may become before it is automatically closed + and a new audit file opened. This is equivalent to an + administrator issuing an \fCaudit -n\fP command when the + audit file contained the specified number of bytes. + The default size is zero (0) which means allow the file to grow + without bound. The value specified must be within the range + of [512,000, 2,147,483,647]. Note the range had been 524,288 [0x80000 - 0xffffffff] 4,294,967,295 but the overflow comparison was broken increment u_int cursize with the I/O size, then compare u_int cursize >= u_int filesz auditon(2): +++++++++++ The following commands are supported: - A_SETFSIZE - Set the maximum size of an audit trail file. When the - audit file reaches the designated size, it is closed and - a new file started. If the maximum size is unset, the - audit trail file generated by auditsvc() will grow to - the size of the file system. The data argument points to - the au_fstat_t structure containing the maximum audit - file size in bytes. The size can not be set less than - 0x80000 bytes. - - A_GETFSIZE - Return the maximum audit file size and current file size - in the au_fstat_t structure pointed to by the data argu- - ment. Notes: ===== [1] audit_startup(1M) is a shell script delivered into /etc/security. It has existed since the 2.3 integration of Audit. It's purpose has varied from release to release. It is executed as part of the start method for the audit service svc:/system/auditd and before auditd(1M) itself is started. From S10, it sets kernel defaults for the audit service. In a future project audit_startup is expected to be eliminated for a proper administrative interface of smf properties to the audit service. From carlsonj@phorcys.east.sun.com Thu Jan 3 06:29:17 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m03ETH9Z026700 for ; Thu, 3 Jan 2008 06:29:17 -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 m03ETCgq006263; Thu, 3 Jan 2008 06:29:15 -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 <0JU20011PO8NCP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Jan 2008 06:29:11 -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 <0JU200LUXO8L86C0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 03 Jan 2008 06:29:09 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m03ERrXn000393; Thu, 03 Jan 2008 09:27:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m03ERrBM000389; Thu, 03 Jan 2008 09:27:53 -0500 (EST) Date: Thu, 03 Jan 2008 09:27:53 -0500 From: James Carlson Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] In-reply-to: <200712220102.lBM12XHE000887@sac.sfbay.sun.com> To: Gary Winiger Cc: psarc-ext@sun.com, Paul.M.Roberts@sun.com Message-id: <18300.61673.638690.909437@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712220102.lBM12XHE000887@sac.sfbay.sun.com> Status: RO Content-Length: 1271 Gary Winiger writes: > I'm sponsoring this case for Paul Roberts and the Audit Project team. > It incompatibly modifies the Evolving auditconfig(1M) and Committed > auditon(2) interfaces to reflect the present implementation. > It requests a Patch release binding and permission to remove the > non-functioning interfaces in a patch even if the replacement functionality > is not present in the same Patch. It'd help a bit to have an evaluation in CR 6185615; I'm missing some background in reading this case. Why not make auditconfig set the new p_fsize parameter in response to the -setfsize keyword, or alternatively have audit_binfile read the parameter on start-up from some common location into which -setfsize writes? I assume there's some sort of timing problem involved, but I'm not sure what it is. It seems a little odd that our response to a broken public interface, with three external customers filing service requests plus internal reports of trouble, and with three escalations, would be to document the brokenness in a patch. -- 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 pr131582@ebusy.uk.sun.com Fri Jan 4 03:52:36 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 m04BqaQR019883 for ; Fri, 4 Jan 2008 03:52:36 -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 m04BqYDO014415; Fri, 4 Jan 2008 04:52:34 -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 <0JU400J0HBNMV600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Jan 2008 03:52:34 -0800 (PST) Received: from ebusy.uk.sun.com ([129.156.173.17]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JU400G6ZBNL4BA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 04 Jan 2008 03:52:34 -0800 (PST) Received: from ebusy.uk.sun.com (localhost [127.0.0.1]) by ebusy.uk.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m04BqXRM010379; Fri, 04 Jan 2008 11:52:33 +0000 (GMT) Received: (from pr131582@localhost) by ebusy.uk.sun.com (8.13.8+Sun/8.13.8/Submit) id m04BqXcJ010339; Fri, 04 Jan 2008 11:52:33 +0000 (GMT) Date: Fri, 04 Jan 2008 11:52:30 +0000 From: Paul Roberts - Sun Microsystems UK Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] In-reply-to: <18300.61673.638690.909437@gargle.gargle.HOWL> To: psarc-ext@sun.com Mail-followup-to: Paul Roberts - Sun Microsystems UK , psarc-ext@sun.com Message-id: <20080104115230.GA2954@ebusy.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200712220102.lBM12XHE000887@sac.sfbay.sun.com> <18300.61673.638690.909437@gargle.gargle.HOWL> User-Agent: Mutt/1.5.16 (2007-06-09) Status: RO Content-Length: 2332 Hi James, On Thu, Jan 03, 2008 at 09:27:53AM -0500, James Carlson wrote: > It'd help a bit to have an evaluation in CR 6185615; I'm missing some > background in reading this case. I've moved one of my comments from that section of the CR into the Evaluation as it seemed to pretty much sum up everything I've come up with so far. Please let me know of any holes that need filling. > Why not make auditconfig set the new p_fsize parameter in response to > the -setfsize keyword, or alternatively have audit_binfile read the > parameter on start-up from some common location into which -setfsize > writes? I assume there's some sort of timing problem involved, but > I'm not sure what it is. I believe that would be possible, and I do not think at first glance that there's a technical argument for not implementing it that way. However, it could be said that the alternative of removing the interface is more in line with the direction that the auditing tools seem to be heading. As I understand it, when auditconfig's '-setfsize' parameter was originally conceived, writing to files on disk was the only auditing method. Now that the actual writing of the data has been abstracted and assigned to multiple plugins, there are theoretically many different backends that could be used to actually write the data (for example the audit_syslog(5) plugin will send the data to syslog instead of writing directly to a file). As such, the concept of a filesize (or even a file) does not necessarily apply to all current and future plugins so it seems reasonable to remove this from the more general auditconfig command and into the individual plugins that need it (and passing keywords via the plugin entries in the audit_control(4) file is the existing method for configuring plugin behavior). If the responsibility remained within auditconfig, depending on the implementation chosen, it may need to know which plugins could use the maximum filesize (in the future there could conceivably be other file-based plugins) and which couldn't. This seems like it could create either too tight a coupling between the auditconfig command and the plugins themselves, or else result in a special method for configuring the audit_binfile(5) plugin which differed from the other plugins (theoretical future plugins that is). Regards, - Paul From gww@eng.sun.com Fri Jan 4 12:37: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 m04KbQui026710 for ; Fri, 4 Jan 2008 12:37:26 -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 m04KbOsB017880 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Jan 2008 20:37:25 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 <0JU400C01ZYCZV00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Jan 2008 12:37:24 -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 <0JU400CEUZYBPL00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Jan 2008 12:37:23 -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 m04KbMGH001447; Fri, 04 Jan 2008 12:37:22 -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 m04KaWWF006337; Fri, 04 Jan 2008 12:36:32 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m04KaWs7006336; Fri, 04 Jan 2008 12:36:32 -0800 (PST) Date: Fri, 04 Jan 2008 12:36:32 -0800 (PST) From: Gary Winiger Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] To: gww@sac.sfbay.sun.com, james.d.carlson@sun.com Cc: Paul.M.Roberts@sun.com, psarc-ext@sun.com Message-id: <200801042036.m04KaWs7006336@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3786 Jim, > Gary Winiger writes: > > I'm sponsoring this case for Paul Roberts and the Audit Project team. > > It incompatibly modifies the Evolving auditconfig(1M) and Committed > > auditon(2) interfaces to reflect the present implementation. > > It requests a Patch release binding and permission to remove the > > non-functioning interfaces in a patch even if the replacement functionality > > is not present in the same Patch. > > It'd help a bit to have an evaluation in CR 6185615; I'm missing some > background in reading this case. I see Paul has updated the bug. I'd thought the one pager of Paul's had sufficient information for this case. > Why not make auditconfig set the new p_fsize parameter in response to > the -setfsize keyword, or alternatively have audit_binfile read the > parameter on start-up from some common location into which -setfsize > writes? I assume there's some sort of timing problem involved, but > I'm not sure what it is. There are a number of reasons that were discussed before making this proposal. I guess things weren't as obvious as they seemed to me. * As I'd hoped was relatively clear from the case materials, -setfsize was the only useful thing to retain. * -setfsize only applies to audit_binfile(5). It seemed appropriate to place the functionality/configuration were it is used. -setfsize/p_fsize causes the currently written audit file to be closed and a new file started when the specified size is reached. Only audit_binfile auditd plugin deals with writing the local audit file. It is possible to provide future plugins that also write to local files, though this would seem unlikely from Sun. Binding configuration to the actual place it is used seems desirable. * It was believed that keeping -setfsize in auditconfig while eliminating -getfsize would be more confusing than eliminating both. * Future work (note [1] of the proposal) is heading to eliminate audit_startup(1M) and audit_control(4) in favor of properties in SMF. Unfortunately the audit project lost the resources that were working on this before the design was finalized. That project would fold the configuration currently done with auditconfig in audit_startup into svc:/system/auditd * Taking a step in that direction seemed useful by binding p_fsize to audit_binfile. The only place that it is at all useful. * Effectively all the auditconfig(1M) functions deal with kernel operations. Indeed -setfsize could continue to write to the kernel and auditd could read from there upon startup or when signaled to refresh. Alternatively -setfsize could be implemented to update audit_control(4), and if svc:/system/auditd was to signal auditd to refresh. * As auditconfig/audit_startup are administrative interfaces rather than APIs in general use, and there really was no practical way to preserve the auditon(2) implementation -- writing info to the kernel without either having auditd poll every time it received kernel data, or have it be signaled by the kernel any time auditon() updated the field seemed excessive, it seemed all right to the Audit Project team to propose what seemed like the most straight forward solution that would be most closely aligned with future work. > It seems a little odd that our response to a broken public interface, > with three external customers filing service requests plus internal > reports of trouble, and with three escalations, would be to document > the brokenness in a patch. As I believe Paul explained (one pager and updated bug), the CU is looking for Sun to say -[gs]etfsize is no longer supported (and to provide the functionality when possible, but not necessarially the syntax). Gary.. From carlsonj@phorcys.east.sun.com Fri Jan 4 13:04: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 m04L45Wc027250 for ; Fri, 4 Jan 2008 13:04:05 -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 m04L42W4007824; Fri, 4 Jan 2008 14:04:03 -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 <0JU500E0H16QA700@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Jan 2008 13:04:02 -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 <0JU500CI016PPS10@nwk-avmta-2.sfbay.sun.com>; Fri, 04 Jan 2008 13:04:02 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m04L2i7C005555; Fri, 04 Jan 2008 16:02:44 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m04L2iRT005552; Fri, 04 Jan 2008 16:02:44 -0500 (EST) Date: Fri, 04 Jan 2008 16:02:43 -0500 From: James Carlson Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] In-reply-to: <200801042036.m04KaWs7006336@marduk.eng.sun.com> To: Gary Winiger Cc: gww@sac.sfbay.sun.com, Paul.M.Roberts@sun.com, psarc-ext@sun.com Message-id: <18302.40691.856373.314624@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801042036.m04KaWs7006336@marduk.eng.sun.com> Status: RO Content-Length: 3487 Gary Winiger writes: > There are a number of reasons that were discussed before making > this proposal. I guess things weren't as obvious as they seemed > to me. > * As I'd hoped was relatively clear from the case materials, > -setfsize was the only useful thing to retain. Sure; that was pretty obvious. I couldn't see why I'd want -getfsize at all. ;-} > * -setfsize only applies to audit_binfile(5). It seemed appropriate > to place the functionality/configuration were it is used. Sure; that was obvious as well. > * It was believed that keeping -setfsize in auditconfig while > eliminating -getfsize would be more confusing than eliminating > both. Really? As things stood before, most users (I think) would be using -setfsize to good effect -- limiting written file size -- and never using -getfsize because "ls" is easier to use. Thus, they'd notice -setfsize disappearing but wouldn't notice only -getfsize going away. At least that was my assumption. > * Future work (note [1] of the proposal) is heading to eliminate > audit_startup(1M) and audit_control(4) in favor of properties > in SMF. Unfortunately the audit project lost the resources that OK. > * Taking a step in that direction seemed useful by binding p_fsize > to audit_binfile. The only place that it is at all useful. Sure; still no problem with that. > * Effectively all the auditconfig(1M) functions deal with kernel > operations. > Indeed -setfsize could continue to write to the kernel > and auditd could read from there upon startup or when signaled > to refresh. > Alternatively -setfsize could be implemented to update > audit_control(4), and if svc:/system/auditd was to signal > auditd to refresh. Sure; both would work. I realize that they're outside your general plans, though. > * As auditconfig/audit_startup are administrative interfaces > rather than APIs in general use, and there really was no practical > way to preserve the auditon(2) implementation -- writing > info to the kernel without either having auditd poll every time > it received kernel data, or have it be signaled by the kernel > any time auditon() updated the field seemed excessive, it seemed > all right to the Audit Project team to propose what seemed like > the most straight forward solution that would be most closely > aligned with future work. Right; that'd be at least a bit ugly. Assuming that you didn't just update audit_control(4) directly (which does look like a viable answer), it'd likely be using the kernel as a storage place for an integer ... so that auditon(2) writes that info, and the plug-in reads it back and uses it. Sort of kludgy, but should work. > > It seems a little odd that our response to a broken public interface, > > with three external customers filing service requests plus internal > > reports of trouble, and with three escalations, would be to document > > the brokenness in a patch. > > As I believe Paul explained (one pager and updated bug), the > CU is looking for Sun to say -[gs]etfsize is no longer supported > (and to provide the functionality when possible, but not > necessarially the syntax). Is this the only customer dependent on the feature? -- 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 Fri Jan 4 17:29:51 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m051TpUm000531 for ; Fri, 4 Jan 2008 17:29:51 -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 m051Todw008003 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Jan 2008 17:29:51 -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 <0JU500307DHPP100@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Jan 2008 17:29:49 -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 <0JU500MJ5DHOTW30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 04 Jan 2008 17:29:48 -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 m051Tkiw012175; Fri, 04 Jan 2008 17:29:46 -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 m051StJE006990; Fri, 04 Jan 2008 17:28:55 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m051Strx006989; Fri, 04 Jan 2008 17:28:55 -0800 (PST) Date: Fri, 04 Jan 2008 17:28:55 -0800 (PST) From: Gary Winiger Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] To: gww@eng.sun.com, james.d.carlson@sun.com Cc: Paul.M.Roberts@sun.com, gww@sac.sfbay.sun.com, psarc-ext@sun.com Message-id: <200801050128.m051Strx006989@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3580 > > * It was believed that keeping -setfsize in auditconfig while > > eliminating -getfsize would be more confusing than eliminating > > both. > > Really? As things stood before, most users (I think) would be using > -setfsize to good effect -- limiting written file size -- and never > using -getfsize because "ls" is easier to use. Well, when -getfsize was working, it reported both the max specified and current size of the file. Indeed audit_binfile could write the current size back to the kernel every time it wrote to the audit file. Performance would suck even worse. It just seems like somthing that can be done without. > Thus, they'd notice -setfsize disappearing but wouldn't notice only > -getfsize going away. At least that was my assumption. The initial report (from Sun UK RPE not external) seems to mention get as not working and that Sun IT had been involved on SunRay server. As these are not really programming interfaces, the Audit Project team would really just like to clean this all up. It should have occured with PSARC/2002/150 or PSARC/2002/665, been announced in S8/S9 and been gone in S10. Unfortunately that didn't occur. So, now we're playing catchup. I think RPE has done a great job with the 3 external CUs who have called this in and escalated. If it wasn't for the escalation, the case would have asked for a Minor release binding. > > * As auditconfig/audit_startup are administrative interfaces > > rather than APIs in general use, and there really was no practical > > way to preserve the auditon(2) implementation -- writing > > info to the kernel without either having auditd poll every time > > it received kernel data, or have it be signaled by the kernel > > any time auditon() updated the field seemed excessive, it seemed > > all right to the Audit Project team to propose what seemed like > > the most straight forward solution that would be most closely > > aligned with future work. > > Right; that'd be at least a bit ugly. Assuming that you didn't just > update audit_control(4) directly (which does look like a viable > answer), it'd likely be using the kernel as a storage place for an > integer ... so that auditon(2) writes that info, and the plug-in reads > it back and uses it. Sort of kludgy, but should work. Indeed, and it doesn't seem good architecture, or to have sufficient value to pursue. > > > with three external customers filing service requests plus internal > > > reports of trouble, and with three escalations, would be to document > > > the brokenness in a patch. > > > > As I believe Paul explained (one pager and updated bug), the > > CU is looking for Sun to say -[gs]etfsize is no longer supported > > (and to provide the functionality when possible, but not > > necessarially the syntax). > > Is this the only customer dependent on the feature? I think there are 3 external CUs. As I understand it from Paul and Brent Paulson (also RPE), they will be happy with an official statement from Sun that these interfaces are not supported on S10, and delighted if there is replacement functionality. The workaround is to monitor the file size and issue an "audit -n" when it gets too large. An alternative to p_fsize was discussed to use logadm, but logadm doesn't seem to have a way to monitor the file size with fine enough time granularity or track the files as they move around from one audit directory to another as file systems fill up, audit_binfile p_dir option. I'll let Paul pipe up here as well ;-) Gary.. From pr131582@estale.uk.sun.com Mon Jan 7 07:54: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 m07Fsrwg010425 for ; Mon, 7 Jan 2008 07:54: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 m07FsgeQ000733; Mon, 7 Jan 2008 08:54:50 -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 <0JUA006016VE6M00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jan 2008 07:54:50 -0800 (PST) Received: from estale.uk.sun.com ([129.156.173.199]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUA00JMP6VCTVB0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jan 2008 07:54:49 -0800 (PST) Received: from estale.uk.sun.com (localhost [127.0.0.1]) by estale.uk.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07Fslxs021052; Mon, 07 Jan 2008 15:54:47 +0000 (GMT) Received: (from pr131582@localhost) by estale.uk.sun.com (8.14.2+Sun/8.14.2/Submit) id m07FskrE021050; Mon, 07 Jan 2008 15:54:46 +0000 (GMT) Date: Mon, 07 Jan 2008 15:54:46 +0000 From: Paul Roberts - Sun Microsystems UK Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] In-reply-to: <200801050128.m051Strx006989@marduk.eng.sun.com> To: psarc-ext@sun.com Cc: Gary Winiger , James.D.Carlson@sun.com Mail-followup-to: Paul Roberts - Sun Microsystems UK , psarc-ext@sun.com, Gary Winiger , James.D.Carlson@sun.com Message-id: <20080107155446.GP14841@estale.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200801050128.m051Strx006989@marduk.eng.sun.com> User-Agent: Mutt/1.5.16 (2007-06-09) Status: RO Content-Length: 2398 Hi, On Fri, Jan 04, 2008 at 05:28:55PM -0800, Gary Winiger wrote: > > Is this the only customer dependent on the feature? > > I think there are 3 external CUs. As I understand it from > Paul and Brent Paulson (also RPE), they will be happy with > an official statement from Sun that these interfaces are > not supported on S10, and delighted if there is replacement > functionality. [...] > I'll let Paul pipe up here as well ;-) That is also my understanding. As for how many customers are using it, I cannot give as thorough an answer as I'd like, but here's my best shot. There are three external service requests on the bug itself but I am afraid I have not been directly involved with their creation so I cannot give full details on how important the feature is to them. As for the three actual Escalations (1-21504816, 1-18652362 and 1-10503277), the first is the on-going customer case that sparked this EOF request. They intend to use auditing in a future S10 roll-out and while investigating that, they discovered that the '-setfsize' feature does not work and escalated it. As Gary suggests, they mostly want to tie up the loose end, and are happy for Sun to document that the feature no longer works by removing it from the existing man pages. Replacement functionality would be welcome though. Escalation 1-18652362 is an external customer escalation, however, reading through the old case notes (RPE was not involved in the escalation) I cannot really get an accurate picture of exactly what happened, but it seems that the customer became unresponsive early on and the issue was never really progressed beyond the initial report. The final escalation 1-10503277 was an internal escalation that was initiated chiefly due to auditing not being large file aware (bug 6261894), for which '-setfsize' was desired as a workaround. Once bug 6261894 was fixed, the internal customer no longer needed to use the '-setfsize' feature and so the escalation was closed. So from these three cases it does not seem there is a high customer demand for the feature (when taken into account alongside the fact that it has been completely non-functional since S10 FCS). Hopefully this helps provide some background. Thanks, - Paul -- Paul Roberts, Solaris RPE Security Vulnerability Team PGP public key: http://rpeweb.uk/~pr131582/publickey.asc Esperanto parolata () From carlsonj@phorcys.east.sun.com Mon Jan 7 08:05:11 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 m07G5AAh010620 for ; Mon, 7 Jan 2008 08:05:11 -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 m07G54tx022634; Tue, 8 Jan 2008 00:05: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 <0JUA0070P7CH2200@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jan 2008 08:05:05 -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 <0JUA00JRA7CETVC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 07 Jan 2008 08:05:03 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m07G3hRS003788; Mon, 07 Jan 2008 11:03:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m07G3h8c003785; Mon, 07 Jan 2008 11:03:43 -0500 (EST) Date: Mon, 07 Jan 2008 11:03:43 -0500 From: James Carlson Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] In-reply-to: <20080107155446.GP14841@estale.uk.sun.com> To: Paul Roberts - Sun Microsystems UK Cc: psarc-ext@sun.com, Gary Winiger Message-id: <18306.19807.871207.1017@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801050128.m051Strx006989@marduk.eng.sun.com> <20080107155446.GP14841@estale.uk.sun.com> Status: RO Content-Length: 659 Paul Roberts - Sun Microsystems UK writes: > So from these three cases it does not seem there is a high customer > demand for the feature (when taken into account alongside the fact > that it has been completely non-functional since S10 FCS). OK; thanks. I think that answers the questions I had ... the bottom line is that it's just considered not likely to be much used or relied on enough that we need to try hard to preserve it. -- 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 Jan 9 10:38:19 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09IcJJ7000928 for ; Wed, 9 Jan 2008 10:38:19 -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 m09IcJZ1016964 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Jan 2008 10:38:19 -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 <0JUE002053RV9B00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 10:38:19 -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 <0JUE00I8W3RUPJD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 10:38:18 -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 m09IcHAk032435; Wed, 09 Jan 2008 10:38:17 -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 m09IbLrY012740; Wed, 09 Jan 2008 10:37:21 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m09IbLBD012739; Wed, 09 Jan 2008 10:37:21 -0800 (PST) Date: Wed, 09 Jan 2008 10:37:21 -0800 (PST) From: Gary Winiger Subject: Re: EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008] To: gww@sac.sfbay.sun.com, psarc-ext@sun.com Cc: paul.m.roberts@sun.com Message-id: <200801091837.m09IbLBD012739@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 458 > I'm sponsoring this case for Paul Roberts and the Audit Project team. > It incompatibly modifies the Evolving auditconfig(1M) and Committed > auditon(2) interfaces to reflect the present implementation. > It requests a Patch release binding and permission to remove the > non-functioning interfaces in a patch even if the replacement functionality > is not present in the same Patch. This case was approved as specified at today's PSARC meeting. Gary..