On Tue, Apr 9, 2019 at 9:53 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2019-04-09 09:40, Paul Moore wrote: > > On Tue, Apr 9, 2019 at 8:58 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > On Tue, Apr 9, 2019 at 5:40 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > > > Add audit container identifier support to the action of signalling the > > > > audit daemon. > > > > > > > > Since this would need to add an element to the audit_sig_info struct, > > > > a new record type AUDIT_SIGNAL_INFO2 was created with a new > > > > audit_sig_info2 struct. Corresponding support is required in the > > > > userspace code to reflect the new record request and reply type. > > > > An older userspace won't break since it won't know to request this > > > > record type. > > > > > > > > Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxx> > > > > > > This looks good to me. > > > > > > Reviewed-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > > > > > > Although I'm wondering if we shouldn't try to future-proof the > > > AUDIT_SIGNAL_INFO2 format somehow, so that we don't need to add > > > another AUDIT_SIGNAL_INFO3 when the need arises to add yet-another > > > identifier to it... The simplest solution I can come up with is to add > > > a "version" field at the beginning (set to 2 initially), then v<N>_len > > > at the beginning of data for version <N>. But maybe this is too > > > complicated for too little gain... > > > > FWIW, I believe the long term solution to this is the fabled netlink > > attribute approach that we haven't talked about in some time, but I > > keep dreaming about (it has been mostly on the back burner becasue 1) > > time and 2) didn't want to impact the audit container ID work). While > > I'm not opposed to trying to make things like this a bit more robust > > by adding version fields and similar things, there are still so many > > (so very many) problems with the audit kernel/userspace interface that > > still need to be addressed. > > While this particular message type is used very infrequently, adding a > version field to every message type strikes me as a huge overhead for > the small likelihood of the format needing to change. > > I'd prefer to just key it off the AUDIT_FEATURE_BITMAP or some other > easily detectable change in this distinguishing feature, such as the > presence of /proc/self/audit_containerid, which is what I've done in the > accompanying userspace patchset that I'm preparing to post that works > with this change. That's fine. As I said, I'm not overly worried about this; I view this as a bit of a necessary hack. -- paul moore www.paul-moore.com
