The CBFilter class offers very flexible security handling. During Control Events, applications can use information obtained from security-related methods to determine whether a request should be allowed as-is, modified before continuing, or denied immediately.
CBFilter provides a number of methods that applications can use to help implement security checks. The most notable of these methods are GetOriginatorProcessName and GetOriginatorProcessId, which return the name and PID of the process that initiated the request; and GetOriginatorToken, which returns the system-defined security token of the process that initiated the request.
The latter is particularly useful when used with various methods in the Windows API, such as the GetTokenInformation function, which can be used to obtain various pieces of information about the object the token is associated with.
As stated above, applications are free to allow/modify/deny any request based on security checks. However, they must not "selectively alter" filesystem information based on these checks, it's "all or nothing". Here are some clarifying examples to help guide implementation:
- A filesystem object cannot appear to exist to process A, but appear nonexistent to process B.
- A filesystem object cannot be reported as a file to process A, but as a directory to process B.
- A filesystem object's metadata, absent of actual changes, must be consistent between requests; e.g., if a file's size is reported as 1 KB to process A, then it must also be reported as 1 KB to process B.
- A file's contents, absent of actual changes, must also be consistent between requests; e.g., for a file whose size is reported as 1 KB, exactly 1024 bytes must be returned when the file is read, and those 1024 bytes must be exactly the same (including ordering) regardless of which process is doing the reading.