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