On Wednesday, May 6, 2020 6:42:33 PM EDT Richard Guy Briggs wrote: > > > > We can't be adding deleting fields based on how its triggered. If > > > > they are unset, that is fine. The main issue is they have to behave > > > > the same. > > > > > > I don't think the intent was to have fields swing in and out depending > > > on trigger. The idea is to potentially permanently not include them in > > > this record type only. The justification is that where they aren't > > > needed for the kernel trigger situation it made sense to delete them > > > because if it is a user context event it will be accompanied by a > > > syscall record that already has that information and there would be no > > > sense in duplicating it. > > > > We should not be adding syscall records to anything that does not result > > from a syscall rule triggering the event. Its very wasteful. More > > wasteful than just adding the necessary fields. > > So what you are saying is you want all the fields that are being > proposed to be added to this record? Yes. > If the records are all from one event, they all should all have the same > timestamp/serial number so that the records are kept together and not > mistaken for multiple events. But NETFILTER_CFG is a simple event known to have only 1 record. > One reason for having information in seperate records is to be able to > filter them either in kernel or in userspace if you don't need certain > records. We can't filter out SYSCALL. -Steve
