[PATCH] audit: Add cmdline to taskinfo output

[Steve Grubb]

On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote:
> On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > > Again... the comm field got cut off and now I have no idea again.
> > 
> > Which is the same as all arches. What I'm trying to say is that all arches
> > would benefit from fixing this problem. I don't like the idea of it
> > getting fixed
> > for one platform and leaving it for all others to figure out another day.
> 
> By arches your don't mean arm right?

Any piece of hardware support the audit code. For example, x86_64/S390/PPC, 
etc.


> This code runs the same on other architectures. If you mean platforms, like
> Android, vs some other Linux distro, then yes I want a generic approach,
> which I think cmdline gets us... no mater how many layers of VM exec/forking
> indirection hell you may find yourself in, you at least get a chance at
> what started the chain. On Android, that happens to be the packagename.

What I'm suggesting is to fix "comm" to have more characters than 16. Which may 
mean getting it from somewhere else, or allowing a slightly bigger storage, or 
allowing an alternate storage in the audit context.


> > Is there some reason that the length of that field must be set to 16? I've
> > seen
> > user id numbers increased by a config option. It might be that the naming
> > convention of android apps is enough to get a change.
> > 
> > > I think exe= in the audit logs is essentially arg[0]... so thats not
> > 
> > going
> > 
> > > to work here,
> 
> We can't change the naming convention of andorid apps, too large of an
> ecosystem to change and no real easy way to be backwards compatible. That
> one is off the table.

That wasn't my suggestion. I was meaning that because of the andriod naming 
convention the current program name storage is useless and might need fixing.


> 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.

-Steve