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:

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

My point is, that comm and cmdline often times differ. JVMs oftren times set the

comm field to some generated thread name via pthreads/prctl interface. Since they

often times differ, I need them both. I even sent an example of this where the comm

field was not what I wanted, and the cmdline field was.

> > 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 patches that set the comm field to the package name submitted to Android, but Dalvik

during execution will adjust the comm field to account for async task naming etc. But even if

we fixed the VM to NOT do this... processes can still have a differing comm title

and cmdline entry.

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

So the bottom line is, I need comm and cmdline, any other approach needs to address

the fact that things can happen via fork and not only exec as well as differing comm and

cmdline fields.

--
Respectfully,

William C Roberts