On Thu, Oct 31, 2013 at 8:28 AM, Richard Guy Briggs <[email protected]> wrote:
> On Thu, Oct 31, 2013 at 08:24:11AM -0700, William Roberts wrote: > > On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <[email protected]> wrote: > > > On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote: > > > > On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <[email protected]> > wrote: > > > > I have compiled kernels in the past with custom COMM widths, but > > > > the memory footprint goes up, at least here were not keeping a > > > > bunch of possibly unused data around in the kernel plus we're not > > > > allocating anything on the common case of it being turned off. > > > > > > I don't like the idea of fields appearing and disappearing. The > > > complaint is "comm" is meaningless. Let's fix that. > > > > Its not that the field is disappearing, its just whether or not you > > want the value printed out. cmdline=(null) vs cmdline="something". > > That's a trivial change of not making it dynamic which is what my > > first patch did but Richard Briggs suggested making it a dynamic > > feature and I was pretty ok with that. > > Ok, so how about both fields are always present, but have some keyword > that is printed that indicates it is a duplicate of the other field? > > Something like cmdline=(comm) > How are you going to detect that cmdlne has changed, its a region of memory in userspace? We would have to cmp the values, and if we cannot detect the transition, this gets more expensive. Also, I have yet to see a case where the above statement is true, so it would be a very infrequent event. However, their is a condition in my patch where an error will cause comm=(null) not to be printed, which could be viewed as a disappearing field. > > > William C Roberts > > - RGB > > -- > Richard Guy Briggs <[email protected]> > Senior Software Engineer > Kernel Security > AMER ENG Base Operating Systems > Remote, Ottawa, Canada > Voice: +1.647.777.2635 > Internal: (81) 32635 > Alt: +1.613.693.0684x3545 > -- Respectfully, William C Roberts
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
