Cc: <alan@...>, <andi@...>, Arjan van de Ven <arjan@...>, Eric Paris <eparis@...>, <hch@...>, <linux-kernel@...>, <malware-list@...>, <malware-list-bounces@...>, <peterz@...>, <viro@...>
the
to
Hm, maybe by implementing a facility with which a client can register it's
interface usage intent? Something like:
register(I_HAVE_NO_INTEREST_IN_CONTENT);
register(I_WANT_TO_EXAMINE_CONTENT);
All former ones would run first because they only want to have the
opportunity to block and do something unrelated to file content (like
HSMs), and later group would be ran last since they want to examine the
content.
Ordering inside those two groups is not important because I don't see how
a model other than restrictive can make sense with content security
scanning.
suggest
The thing is the idea never was for clean-dirty "database" to be
persistent but to have the same lifetime as the inode (in memory one). And
once the cache/database gets invalidated re-scanning happens on-demand so
the 5TB problem does not exist. Concerns about multiple clients where
every has a different versioning scheme are also not relevant with the
proposed versioning scheme (see my reply to Arjan).
So this problem can be solved in kernel in a much more performant and
secure way than it would be possible in userspace and all that with just a
handfull of lines of code.
--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos
"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
