Will the ES_EVENT_TYPE_NOTIFY_OPEN
event be called back when the user has already returned es_respond_flags_result(client, msg, 0, false)
in ES_EVENT_TYPE_AUTH_OPEN
?
I believe the ES_EVENT_TYPE_NOTIFY_OPEN
event should not be triggered if the user has already denied the open operation in the ES_EVENT_TYPE_AUTH_OPEN
response handler. However, during my testing, ES_EVENT_TYPE_NOTIFY_OPEN
was still being called even after I blocked the open process. Is this behavior correct?
Will the ES_EVENT_TYPE_NOTIFY_OPEN event be called back when the user has already returned es_respond_flags_result(client, msg, 0, false) in ES_EVENT_TYPE_AUTH_OPEN?
Yes. In terms of the code flow inside the ES system, both of those event are triggered by exactly the same kauth check and processed by the same event flow inside the ES system.
However, during my testing, ES_EVENT_TYPE_NOTIFY_OPEN was still being called even after I blocked the open process. Is this behavior correct?
Yes. By design, the difference between a "NOTIFY" event and it's corresponding "AUTH" event is simply that the auth event can deny the action, NOT the trigger or meaning of the event itself. That approach was chosen to both minimize callouts from the kernel and to provide a "symmetrical" API.
One point to understand here:
I believe the ES_EVENT_TYPE_NOTIFY_OPEN event should not be triggered if the user has already denied the open operation in the ES_EVENT_TYPE_AUTH_OPEN response handler.
In general, most (probably all?) ES events occur VERY early in the processing of a given syscall, often as the FIRST check that event receives. That means that authorizing a given event simply means that you didn't block the event, NOT that the operation actually "worked". Taking "open" as an example, the ES check occurs before the system has checked with underlying file system to validate access, so I believe you'll receive auth calls for files where basic UNIX permission will already block the open.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware