I am creating a parser/converter from the Linux Audit format. As I was studying the format, looking at examples and reading the documentation I stumbled upon a problem.

Can I be sure that the field names inside a single record are unique?

For example, is a record like this one is legal / appear in real world implementations:

type=TYPE msg=audit(1.002:3): msg="the first msg field" msg="the second msg field"

The second related question is whether I can there are there will be only one pid in an event? For example, is this event is legal / appear in real world implementations:

type=TYPE1 msg=audit(1.002:3): pid=0 msg="texthere"
type=TYPE2 msg=audit(1.002:3): pid=0 msg="differenttexthere"
  • I see you created the tag linux-audit. That's meant to be a synonym of auditd, right? – Gilles 'SO- stop being evil' Aug 1 '16 at 15:21
  • @Gilles, I am not sure about it. I see auditd as the userspace daemon mostly. Linux Audit is a much wider tag which might include questions about the standard itself. I am working a lot with the Linux Audit format documentation lately and I've been missing a proper tag for my questions. audit seems to be too general and auditd is not really the tag I need. This is why I decided to create the linux-audit tag. – Mateusz Piotrowski Aug 1 '16 at 15:25
  • auditd wasn't used specifically about the daemon, it was about the whole framework (auditd, auditctl and other related tools). Is there a difference between the Linux audit framework and the Linux audit standard? Please chime in on the meta thread. – Gilles 'SO- stop being evil' Aug 1 '16 at 23:43

According to Steve Grubb's reply on the official mailing list (link to the email):

Steve's answer:

Is it possible that there are duplicate fields in a record?

Sometimes. I've tried to fix those when it happens. The problem is that not everyone runs their audit code by this mail list so that we can check it to see that its well formed. What I am planning to do is write an audit event validation suite that checks that events are well formed and that expected events are being written when they are supposed to and in the order that they are supoosed to. Cleaning up these events is high on my TODO list.

Something like (which doesn’t make much sense obviously):

    type=CWD msg=audit(1464013682.961:409):  cwd="/root” cwd=“/usr”

Something like this will not happen, its more likely around auid and uid. The reason being that the kernel adds somethings automatically because its a trusted source of information. User space can write contradictory information. For example if a daemon is working on behalf of a user but its auid has not been set for the user, then you might see this.


It is possible however it is uncommon and discouraged.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.