EOF and removal of auditconfig -[gs]etfsize [PSARC/2007/701 FastTrack timeout 01/09/2008]

[James Carlson]

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              <james.d.carlson at sun.com>
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