Description of problem:
When adding excludes to audit-exec watches (like backup or other agents) which are not commonly installed and missing on a machine, the auditctl raises an error about "No such file or directory" on loading such common ruling.
Version-Release number of selected component (if applicable):
(Re)-load of audit-rules containing excludes on exec-watches for files which do not exist and also the parent directory does not exist.
Steps to Reproduce:
1. Add exec-exclude rule to audit:
-a never,exit -F arch=b64 -S execve -F exe=/nonexisting-dir/nonexisting-exec
2. Reload audit rules
3. Get error
The user is faced with a "No such file or directory" message.
Audit silently skips that rule, or raises a warning
The customer is running at least two different types of machines, having different agents in place. As they are monitoring exec calls and those agents bloat the logs, they added this exclude. But this agent not installed at any machine and the ones lacking the installation are currently refusing to load that audit-ruling.
When creating the parent directory of that exclude (and of course it's parents as well), the exclude is accepted and auditd adds the rules. For the given example, "/nonexisting-dir" will need to exist to load the rule.
The audit system is really based on inodes and devices - meaning numbers. When the rule is loaded, it tries to map the rule to the device/inode so that it can do the right thing. If the file is missing, then this mapping will fail. The best thing to do it tell auditd to ignore the failure with either the -c or the -i option. Also, the audit daemon's rules are meant to be modular. Meaning that the rules file can be broken into 2 and dropped into /etc/audit/rules.d/ The machine that has the file can get both rule files and the machine without it can get only one rule file. This is another and better way of handling this kind of problem.
In short, I think the audit system is working per design. This just needs to be worked around on the user's end by ignoring the issue or decomposing the rules.
(In reply to Steve Grubb from comment #3)
> The audit system is really based on inodes and devices - meaning numbers.
> When the rule is loaded, it tries to map the rule to the device/inode so
> that it can do the right thing. If the file is missing, then this mapping
> will fail. The best thing to do it tell auditd to ignore the failure with
> either the -c or the -i option. Also, the audit daemon's rules are meant to
> be modular. Meaning that the rules file can be broken into 2 and dropped
> into /etc/audit/rules.d/ The machine that has the file can get both rule
> files and the machine without it can get only one rule file. This is another
> and better way of handling this kind of problem.
AFAIK "augenrules" will merge the files from rules.d to build a audit.rules which then will be loaded - having a missing file in an exclude will render auditd to bail out with an error and ignoring further rules.
> In short, I think the audit system is working per design. This just needs to
> be worked around on the user's end by ignoring the issue or decomposing the
Probably one improvement would be to have "exclude" rules with missing files to raise a warning instead of raising this as an error. Adding "-c" or "-i" would additionally ignore other, and probably more critical errors in the audit.rules as well. In that case the user may want to have auditd to refuse loading the rules. With exceptions, I would consider this as a warning by default instead of errors.
Hope that this explains the requested change.
The way that the kernel works is that if the file does exist but the directory does, then it accepts the rule in case the file is created. If the directory doesn't exist, then the kernel returns an error and auditctl passes that to the user. This is how it's designed to work. We really can't tell the difference between /tmp and /ttmp. If we start ignoring errors and you typed ttmp when you meant tmp, how do we know? It's best to just flag that as a problem and let someone fix it.
Closing out this bz. I think everything is working as intended. The design is to get someone's attention in case there is a typo which cannot be determined programmatically.