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
