<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <span dir="ltr"><<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote:<br>
> On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>> wrote:<br>
</div><div class="im">> > > > Again... the comm field got cut off and now I have no idea again.<br>
> ><br>
> > Which is the same as all arches. What I'm trying to say is that all arches<br>
> > would benefit from fixing this problem. I don't like the idea of it<br>
> > getting fixed<br>
> > for one platform and leaving it for all others to figure out another day.<br>
><br>
> By arches your don't mean arm right?<br>
<br>
</div>Any piece of hardware support the audit code. For example, x86_64/S390/PPC,<br>
etc.<br>
<div class="im"><br>
<br>
> This code runs the same on other architectures. If you mean platforms, like<br>
> Android, vs some other Linux distro, then yes I want a generic approach,<br>
> which I think cmdline gets us... no mater how many layers of VM exec/forking<br>
> indirection hell you may find yourself in, you at least get a chance at<br>
> what started the chain. On Android, that happens to be the packagename.<br>
<br>
</div>What I'm suggesting is to fix "comm" to have more characters than 16. Which may<br>
mean getting it from somewhere else, or allowing a slightly bigger storage, or<br>
allowing an alternate storage in the audit context.<br></blockquote><div><br></div><div>My point is, that comm and cmdline often times differ. JVMs oftren times set the</div><div>comm field to some generated thread name via pthreads/prctl interface. Since they</div>
<div>often times differ, I need them both. I even sent an example of this where the comm</div><div>field was not what I wanted, and the cmdline field was.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> > Is there some reason that the length of that field must be set to 16? I've<br>
> > seen<br>
> > user id numbers increased by a config option. It might be that the naming<br>
> > convention of android apps is enough to get a change.<br>
> ><br>
> > > I think exe= in the audit logs is essentially arg[0]... so thats not<br>
> ><br>
> > going<br>
> ><br>
> > > to work here,<br>
><br>
> We can't change the naming convention of andorid apps, too large of an<br>
> ecosystem to change and no real easy way to be backwards compatible. That<br>
> one is off the table.<br>
<br>
</div>That wasn't my suggestion. I was meaning that because of the andriod naming<br>
convention the current program name storage is useless and might need fixing.<br></blockquote><div><br></div><div>I have patches that set the comm field to the package name submitted to Android, but Dalvik</div><div>during execution will adjust the comm field to account for async task naming etc. But even if</div>
<div>we fixed the VM to NOT do this... processes can still have a differing comm title</div><div>and cmdline entry.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> I have compiled kernels in the past with custom COMM widths, but the memory<br>
> footprint goes up, at least here were not keeping a bunch of possibly unused<br>
> data around in the kernel plus we're not allocating anything on the common<br>
> case of it being turned off.<br>
<br>
</div>I don't like the idea of fields appearing and disappearing. The complaint is<br>
"comm" is meaningless. Let's fix that.<br></blockquote><div><br></div><div>Its not that the field is disappearing, its just whether or not you want the value</div><div>printed out. cmdline=(null) vs cmdline="something". That's a trivial change of not</div>
<div>making it dynamic which is what my first patch did but Richard Briggs suggested</div><div>making it a dynamic feature and I was pretty ok with that.</div><div><br></div><div>So the bottom line is, I need comm and cmdline, any other approach needs to address</div>
<div>the fact that things can happen via fork and not only exec as well as differing comm and</div><div>cmdline fields.</div><div><br></div></div>-- <br>Respectfully,<br><br>William C Roberts<br><br>
</div></div>