Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Casey Schaufler
Klaus Heinrich Kiwi wrote: On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote: And any code created needs to be backwards compatible. you could have new user space/new kernel, or new user space/old kernel, and new kernel/old user space. You have no way of dictating which versions of anythi

Re: [RFC][PATCH] audit: get inode pathname patch

2008-08-13 Thread Mimi Zohar
On Tue, 2008-08-12 at 19:47 -0400, Steve Grubb wrote: > On Wednesday 06 August 2008 10:36:46 Mimi Zohar wrote: > > We are interested in using auditing's context pathname information. > > Is this the best way of accessing it? > > > > Add support for accessing auditing's inode full pathname. > > W

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread John Dennis
Linda Knippers wrote: Steve Grubb wrote: In a binary representation, you would have a version number to describe what structure to cast the pointer to. If you have new log with old user space, it won't parse because it won't have the template to cast with. Is that any different from not bein

audit-viewer error

2008-08-13 Thread LC Bruzenak
My audit-viewer (audit-viewer-0.3-1) crashes at startup with the following: Traceback (most recent call last): File "/usr/share/audit-viewer/main.py", line 71, in if w.setup_initial_window(args): File "/usr/share/audit-viewer/main_window.py", line 158, in setup_initial_window self.new

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Linda Knippers
Steve Grubb wrote: On Wednesday 13 August 2008 12:25:09 Klaus Heinrich Kiwi wrote: I like Mathew's idea of having a binary format though. Maybe it's possible to carry the legacy format for some time while we have a more robust (and extensible) binary format in parallel? And then having a binary

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread LC Bruzenak
On Wed, 2008-08-13 at 13:02 -0400, Steve Grubb wrote: > > > There is a problem with any format. How would changing to binary help > when we realize that we forgot auid in CONFIG_CHANGE? The only thing > that might help is to stab a version number into each record because > its size is going to c

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Steve Grubb
On Wednesday 13 August 2008 12:25:09 Klaus Heinrich Kiwi wrote: > I like Mathew's idea of having a binary format though. Maybe it's > possible to carry the legacy format for some time while we have a more > robust (and extensible) binary format in parallel? And then having a > binary format version

get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Jonathan Kelly
Hi again, For what it's worth, I dug through the code a bit, and am pretty sure that this particular issue exists in lines 71-78 of ellist.c: ptr = strtok_r(buf, " ", &saved); if (ptr == NULL) return -1; do {// If there's an '=' sign, its a keeper

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread John Dennis
Eric Paris wrote: On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote: I think that if we take this discussion to extremes, we'd be talking about a 'self-descriptive meta language' so that upgrades to userspace/kernel are well covered (can you say "xml"?) HAHAHA, kernel output

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Klaus Heinrich Kiwi
On Wed, 2008-08-13 at 11:09 -0400, Eric Paris wrote: > HAHAHA, kernel output xml? dream on :) I'm willing to do > wholesale > output changes, but something that heavy in kernel is impossible to > push. I can just see Al cussing up a storm as he read that. That's exactly my point. There's no

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Eric Paris
On Tue, 2008-08-12 at 21:33 -0300, Klaus Heinrich Kiwi wrote: > On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote: > > > > And any code created needs to be backwards compatible. you could have new > > user > > space/new kernel, or new user space/old kernel, and new kernel/old user > > space.

Re: get_field_str() and interpret_field() bug with multi-word fields

2008-08-13 Thread Klaus Heinrich Kiwi
On Tue, 2008-08-12 at 16:32 -0400, Steve Grubb wrote: > > And any code created needs to be backwards compatible. you could have new > user > space/new kernel, or new user space/old kernel, and new kernel/old user > space. You have no way of dictating which versions of anything people will > us