want
In general this metadata provides more context to the event that happened.
For example reporting - log message/UI popup/centralised something can be
displayed saying which user running which application was involved with
bad stuff. Also we can find out where the user is logged in and send him a
message there.
It is more descriptive than just failing the access with -EACCESS which
becomes ambigious.
/sys
excluded
Agreed.
them
we
When you don't run an userspace client cache should not come into play
because nothing will be cached (in this iteration at least). So I guess
you meant something different here? Like not running an userspace client
and having the filter disabled (or even not) will produce very little
overhead, probably not observable without micro-benchmarking. Having an
userspace client which just replies with "allow" should have even less
performance impact because most inodes will get cached which means filter
chain will be shorter on subsequent accesses to the same inode.
In either case it will become obvious how huge performance win is to have
in kernel caching once you get the numbers. Let me know if I can help you
with that somehow.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--