Gary Winiger wrote:
>>
> I understand it's waiting need spec -- for different reasons.
> My motivation for posting was to add to the new specs completeness
> for whatever audit architecture was needed.
> Darren says this has nothing to do with this project. I disagree,
> past ignorance in granting approvals with missing architecture
> should not be criteria for approving current projects once the
> past oversites are identified.
> As the this project team (the Power management team) and the
> Audit project team will need to cooperate on other parts of
> audit being directly introduced by this project, it is appropriate
> to extend this cooperation to resolve the past architectural
> oversites. IMO, they are likely to add very little additional
> project team work beyond fleshing out the ignorance.
>
Gary,
I'm a little confused here. My understanding is that the project merely
calls other components which (hopefully) take care of the auditing. The
auditing needs to happen in the core bits (either commands, libraries,
or kernel bits) -- i.e. it shouldn't matter whether the suspend is
happening as a result of hald, a sysadmin manually typing uadmin, or
some other process -- the audit still needs to occur. If the GPM
project is going to just consume other software which properly handles
auditing, apart from ensuring that the consumed bits actually *do*
conform to auditing requirements, what else is there for this project to do?
Do you believe that a different kind of audit trail should be recorded
by this project than if, for example, the sysadmin just types the uadmin
command with the magic number arguments?
Now if it turns out that the various facilities which GPM makes use of
*don't* do the necessary auditing, then I agree there is a problem. (In
which case, architecturally, I think the right thing to do is file a bug
-- and maybe an associated fasttrack or self-review case -- against
those components, and note that the fix for said bug is just a
pre-requisite for this project.)
-- Garrett
