Re: [PATCH] audit: Add cmdline to taskinfo output
On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <sgrubb(a)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(a)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
Attachments:
- attachment.html (text/html — 4.7 KB)