On Fri, Mar 13, 2020 at 3:23 PM Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2020-03-13 12:42, Paul Moore wrote:
...
> The thread has had a lot of starts/stops, so I may be repeating
a
> previous suggestion, but one idea would be to still emit a "death
> record" when the final task in the audit container ID does die, but
> block the particular audit container ID from reuse until it the
> SIGNAL2 info has been reported. This gives us the timely ACID death
> notification while still preventing confusion and ambiguity caused by
> potentially reusing the ACID before the SIGNAL2 record has been sent;
> there is a small nit about the ACID being present in the SIGNAL2
> *after* its death, but I think that can be easily explained and
> understood by admins.
Thinking quickly about possible technical solutions to this, maybe it
makes sense to have two counters on a contobj so that we know when the
last process in that container exits and can issue the death
certificate, but we still block reuse of it until all further references
to it have been resolved. This will likely also make it possible to
report the full contid chain in SIGNAL2 records. This will eliminate
some of the issues we are discussing with regards to passing a contobj
vs a contid to the audit_log_contid function, but won't eliminate them
all because there are still some contids that won't have an object
associated with them to make it impossible to look them up in the
contobj lists.
I'm not sure you need a full second counter, I imagine a simple flag
would be okay. I think you just something to indicate that this ACID
object is marked as "dead" but it still being held for sanity reasons
and should not be reused.
--
paul moore
www.paul-moore.com