Log Dejargonizer

Linux Audit Framework · Event PATH

auditd type=PATH: which file the operation actually touched

The PATH records name the files involved in an audited operation. One action usually produces several of them, and only one is the file you care about — the nametype field is what tells you which, and it is the field most people never read.

Also written as type=PATHauditd PATH recordauditd nametype PARENTaudit log inode ouid

What it means for you

For an analyst

Creating a file emits a PARENT record for the directory and a CREATE record for the file, so a naive query that takes the first PATH in an event reports the directory instead of the file — a classic source of confusing detections. Two further points. The name field is recorded as given to the syscall, so a relative path needs the CWD record from the same event to resolve, and a rule matching on absolute paths will not see it. And the ouid field is the owner of the object, distinct from the uid in the SYSCALL record, which makes it the field that answers whose file was touched rather than who touched it.

The fields that decide it

Everything else in the log line is context.

nametype
What role this path played in the operation. The field that decides which PATH record you actually want.
  • PARENTThe containing directory, recorded because it had to be looked up. Rarely the file of interest.
  • CREATEA file that was created. This is the one you want when hunting for new files.
  • DELETEA file that was removed.
  • NORMALAn existing file that was read, written, or opened.
  • UNKNOWNThe kernel could not classify it, usually a failed lookup.
name
The path as passed to the syscall. Relative paths need the CWD record from the same event to resolve — the audit log does not do that for you.
inode and dev
The filesystem identifiers. These follow a file across renames, which makes them the way to track a file that has been moved rather than copied.
ouid and ogid
The owner of the object, as distinct from who performed the operation. This is how you tell that a user touched another user's file.
mode
The permission bits, in octal, with a leading type digit. Values with the setuid bit set are worth noticing on newly created files.

Common questions

Why does one file operation produce several PATH records?

Because the kernel records every path it had to resolve. Creating a file emits one record for the parent directory and one for the new file; a rename emits records for both the source and the destination and for both parent directories. The nametype field distinguishes them, and reading it is what stops you reporting a directory when you meant a file.

How do I find newly created files in the audit log?

Filter on PATH records with nametype=CREATE rather than on syscall names, because several different syscalls create files and the record type is more reliable than guessing which ones. Then read the name field, resolving it against the CWD record from the same event if it is relative.

The path in the record is relative. How do I get the full path?

From the CWD record in the same event group, which holds the working directory at the time. ausearch keeps the group together so both are in front of you; grep does not, which is why relative paths look unresolvable when you search the raw file. This is also why audit rules that watch absolute paths can miss access made from inside the directory.

What is the difference between ouid and uid in an audit event?

uid, in the SYSCALL record, is who performed the operation. ouid, in the PATH record, is who owns the file that was operated on. The interesting cases are where they differ — one user reading or writing another user's files — and that comparison is only possible because the two values live in different records of the same event.

Read next

Vendor documentation

Last reviewed 6 September 2026