But lets talk about a real design and what people want to see.
Userspace program needs to 'register' with a priority. HSMs would want
a low priority on the blocking calls AV Scanners would want a higher
priority and indexers would want a very high priority.
On async notification we fire a message to everything that registered
'simultaneously.' On blocking we fire a message to everything in
priority order and block until we get a response. That response should
be of the form ALLOW/DENY and should include "mark result"/"don't mark
result."
If everything responds with ALLOW/"mark result" we will flip a bit IN
CORE so operations on that inode are free from then on. If any program
responds with DENY/"mark result" we will flip the negative bit IN CORE
so deny operations on the inode are free from then on.
Userspace 'scanners' if intelligent should have set a timespace in a
particular xattr of their choosing to do their own userspace results
caching to speed up things if the inode is evicted from core. This
means that the 'normal' flow of operations for an inode will look like:
open -> async to userspace -> userspace scans and writes timestamp
read -> blocking to userspace -> userspace checks xattr timestamp and
mtime and responds with ALLOW/"mark result"
read -> we have the ALLOW/mark result bit in core set so just allow.
mtime update -> clear ALLOW/"mark result" bit in core, send async
notification to userspace
close -> send async notification to userspace
If some general xattr namespace is agreed upon for such a thing someday
a patch may be acceptable to clear that namespace on mtime update, but I
don't plan to do that at this time since comparing the timestamp in the
xattr vs mtime should be good enough.
******************************
Great, how to build this interface. THIS IS WHAT I ACTUALLY CARE ABOUT
The communication with userspace has a very specific need. The scanning
process needs to get 'something' that will give it access to the
original file/inode/data being worked on. My previous patch set does
this with a special securityfs file. Scanners would block on 'read.'
This block was waiting for something to be scanned and when available a
dentry_open() was called in the context of the scanner for the inode in
question. This means that the fd in the scanner had to be the same data
as the fd in the original process.
If people want me to use something like netlink to send async
notifications to the scanner how do I also get the file/inode/data to
the scanning process? Can anyone think of a better/cleaner method to
get a file descriptor into the context of the scanner other than having
the scanner block/poll on a special file inside the securityfs?