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..
