Klaus Weidner wrote: > On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda Knippers wrote: > >>In this bugzilla, Eduardo has accurately described the behavior of cups if >>auditd is running when cupsd starts up but auditd is stopped afterwards. >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 >> >>He was expecting cupsd to stop printing (not an unreasonable expectation) >>but it does not. >> >>I updated the bugzilla to explain why and to point out that lots of >>trusted programs issue audit records at the completion of some operation >>(they include the results in the audit record) and don't undo the operation >>if issuing the audit record fails. We could certainly change cupsd to >>fail to queue a job or to cancel a job if it can't be audited but what >>about the other programs? >> >>I know we talked about this alot when the audit failure action >>routine was added the libaudit but the requirements were never >>very clear. > > > The only directly relevant requirement from LSPP is that any actions > which would normally be audited must be prevented when the audit trail is > full.
Ok, so same requirement as for CAPP. > There is no requirement for preventing actions when the admin has > intentionally disabled audit, or if audit is not working for some reason > other than a full audit trail. And in the log or disk full case, we take the action before the disk is actually full so we shouldn't be losing anything. I think we can close this bz as not a bug. Thanks. > There is a special case for the secure failure mode in pam_loginuid, > where login is prevented if auditd is not running. This is done to ensure > that the association between user actions and their identity is reliable. -- ljk -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
