public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
* file watch question
@ 2013-08-16 20:19 LC Bruzenak
  2013-08-16 21:32 ` LC Bruzenak
  0 siblings, 1 reply; 3+ messages in thread
From: LC Bruzenak @ 2013-08-16 20:19 UTC (permalink / raw)
  To: linux-audit

Reading the man page for auditctl, looking at file watch rules I see this:

      -w path
              Insert a watch for the file system object at path. You
cannot insert a watch to the top level directory. This is prohibited by 
the  kernel.
              Wildcards  are not supported either and will generate a
warning. The way that watches work is by tracking the inode internally.
If you place
              a watch on a file, its the same as using the -F path
option on a syscall rule. If you place a watch on a directory, its the 
same  as  using
              the  -F  dir  option  on  a  syscall  rule. The -w form of
writing watches is for backwards compatibility and the syscall based
form is more
              expressive. Unlike most syscall auditing rules, watches do
not impact performance based on the number of rules sent to the kernel.
The  only
              valid  options when using a watch are the -p and -k. If
you need to anything fancy like audit a specific user accessing a file,
then use the
              syscall auditing form with the path or dir fields. See the
EXAMPLES section for an example of converting one form to another.

I assume if the "-w form" is just backwards-compatible, it is preferred
to use the syscall method.
Question -
The line saying, "Unlike most syscall auditing rules, watches do not
impact performance based on the number of rules sent to the kernel" -
does this mean that BOTH the "-w" and "syscall" rules have no
performance impact?

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: file watch question
  2013-08-16 20:19 file watch question LC Bruzenak
@ 2013-08-16 21:32 ` LC Bruzenak
  2013-08-16 22:08   ` Steve Grubb
  0 siblings, 1 reply; 3+ messages in thread
From: LC Bruzenak @ 2013-08-16 21:32 UTC (permalink / raw)
  To: linux-audit

On 08/16/2013 03:19 PM, LC Bruzenak wrote:
> The line saying, "Unlike most syscall auditing rules, watches do not
> impact performance based on the number of rules sent to the kernel" -
> does this mean that BOTH the "-w" and "syscall" rules have no
> performance impact?
>
> Thx,
> LCB
>
Nevermind; I see that the rule in force (with auditctl -l) is the same
regardless of the way it is specified in the auditctl line.

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: file watch question
  2013-08-16 21:32 ` LC Bruzenak
@ 2013-08-16 22:08   ` Steve Grubb
  0 siblings, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2013-08-16 22:08 UTC (permalink / raw)
  To: linux-audit

On Friday, August 16, 2013 04:32:25 PM LC Bruzenak wrote:
> On 08/16/2013 03:19 PM, LC Bruzenak wrote:
> > The line saying, "Unlike most syscall auditing rules, watches do not
> > impact performance based on the number of rules sent to the kernel" -
> > does this mean that BOTH the "-w" and "syscall" rules have no
> > performance impact?
> 
> Nevermind; I see that the rule in force (with auditctl -l) is the same
> regardless of the way it is specified in the auditctl line.

The -w form is for backward compatibility with the original patch. It also 
turns out to be more concise to type. But auditctl translates it to a syscall 
rule with the -F path or -F dir depending on what it detects the object to be 
at rule loading time. The Syscall form does allow more fine grained control.

The reason it doesn't have performance impact like normal syscall rules is 
because it gets moved to a list that is not evaluated every syscall. A normal 
syscall rule will get evaluated for every syscall because it has to see if the 
syscall number is of interest and then it checks the next rule. All of my 
attempts to measure performance impact of watches showed that its in the cache 
noise.

Last time I measured was about 7 years ago but I don't think anything has 
changed that would affect the old results.

http://people.redhat.com/sgrubb/files/watch-perf.tar.gz

-Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-08-16 22:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-16 20:19 file watch question LC Bruzenak
2013-08-16 21:32 ` LC Bruzenak
2013-08-16 22:08   ` Steve Grubb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox