Re: [PATCH] audit: Add cmdline to taskinfo output

William Roberts
2013-10-31T15:52:23Z

[-- Attachment #1.1: Type: text/plain, Size: 3230 bytes --]

On Thu, Oct 31, 2013 at 8:51 AM, William Roberts
<bill.c.roberts@gmail.com>wrote:

>
>
>
> On Thu, Oct 31, 2013 at 8:46 AM, Richard Guy Briggs <rgb@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 <rgb@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 <sgrubb@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 <
>> sgrubb@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 <rbriggs@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

[-- Attachment #1.2: Type: text/html, Size: 5486 bytes --]