auparse_interpret_field()

[klausk at br.ibm.com]

Steve Grubb <sgrubb at redhat.com> wrote on 11/09/2007 12:56:41 PM:

> On Friday 09 November 2007 12:15:43 klausk at br.ibm.com wrote:
> > Trying to debug this problem, I saw that it's happening because the 
record
> > 'machine' field in the auparse internal structure is set to '-1':
> 
> That would do it. Now...how did that happen? arch says its a 64 bit S390 

> machine.
> 
>From ellist.c, function parse_up_record():
                        } else if(r->nv.cnt == 2 && strcmp(n.name, 
"arch")== 0){
                                unsigned int ival;
                                errno = 0;
                                ival = strtoul(n.val, NULL, 16);
                                if (errno) 
                                        r->machine = -1;
                                r->machine = audit_elf_to_machine(ival);
                        } else if(r->nv.cnt == 3 && strcmp(n.name,
                                                        "syscall") == 0){
                                errno = 0;
                                r->syscall = strtoul(n.val, NULL, 10);
                                if (errno)
                                        r->syscall = -1;

See that 'r->machine' and 'r->syscall' are only filled when the 'arch' 
field in found in the 2nd position, and syscall in the 3rd position 
respectively. That is not true when the dispatcher is appending a 'node=' 
field to each record.

I just confirmed this behavior by setting 'name_format = NONE' in the 
audispd configuration, and then I was capable of seeing the 'arch=' field 
correctly interpreted to 's390x'

I would provide a patch myself, but I'm not sure why you need to check the 
field position in this function (I mean, if the field is arch=, wouldn't 
it be interpreted no matter what position it is?)

Thoughts?

 Thanks,
 Klaus
-- 
Klaus Heinrich Kiwi/Brazil/IBM <klausk at br.ibm.com>
Software Engineer
IBM STG, Linux Technology Center
Phone:(+55-19) 2132-1909 [T/L 839-1909]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20071109/e08d5382/attachment.htm>