On Thu, Oct 31, 2013 at 8:51 AM, William Roberts <bill.c.robe...@gmail.com>wrote:
> > > > On Thu, Oct 31, 2013 at 8:46 AM, Richard Guy Briggs <r...@redhat.com>wrote: > >> On Thu, Oct 31, 2013 at 08:33:34AM -0700, William Roberts wrote: >> > On Thu, Oct 31, 2013 at 8:28 AM, Richard Guy Briggs <r...@redhat.com> >> 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 <sgr...@redhat.com> >> wrote: >> > > > > On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote: >> > > > > > On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb < >> sgr...@redhat.com> 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. >> >> Is it likely that those two point to the same region of memory? If so, >> just compare the pointers. >> > > no cmdline is mapped into the user process, cmdline is mapped into the > kernel, so their > virtual addresses and pa's are different (hopefully or I don't understand > mmu based memory management) > > Sorry incorrect above: cmdline --> user process comm --> Kernel process > >> > 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. >> >> Would it be useful if this condition were changed to print instead >> comm=(error)? >> > > It could be, but ideally we should printk the error too.... someone can > arbitrarily set their > proc cmdline entry or tsk comm to something "reserved" > > >> >> > > > William C Roberts >> > > >> > > - RGB >> > >> > William C Roberts >> >> - RGB >> >> -- >> Richard Guy Briggs <rbri...@redhat.com> >> 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 > > -- Respectfully, William C Roberts
-- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit