- is there going to be a way to check the deadline was missed and ES replied?
- what file open flags are going to be used?
es_set_deadline_max_milliseconds()
- is there a limit for the max value?
- can we apply it for all event types or are there any limitations?
- es_set_deadline_min_milliseconds() is for ES descendants clients but the
set_deadline_maxversion does not mention descendants in the description. Is it just missed in the description?
Could you describe intended usage of the descendant ES clients a bit more, please?
Are the reserved ES events (like the one for pasteboard) preparation for potential public use or are they solely intended for internal use?
is there going to be a way to check the deadline was missed and ES replied?
There already is: ES_RESPOND_RESULT_ERR_DUPLICATE_RESPONSE
what file open flags are going to be used?
When using ALLOW or DENY as the miss mode the result is not cached, so the particular open event you miss is just allowed or denied. Open flags only matter for caching.
is there a limit for the max value?
Read the header doc carefully.
es_set_deadline_max_milliseconds() allows you to set the maximum deadline, not the deadline. There is no upper limit but as it's a maximum value it can only be used to decrease deadlines.
If the deadline is say 10 units, then min(15,10) = 10. Setting the deadline maximum to 15 has no affect on a deadline of 10.
es_set_deadline_max_milliseconds() is the deadline ceiling. You can use it only to reduce deadlines.
es_set_deadline_min_milliseconds() is the deadline floor, it raises deadlines. It can only be used with descendants clients because descendants clients are programs the caller could already just kill or suspend anyway. A critical system daemon will never be a descendant.
can we apply it for all event types or are there any limitations?
deadline min and max can be set for all events.
Could you describe intended usage of the descendant ES clients a bit more, please?
Normally ES clients must run as root because they cross user boundaries, they require TCC_ALL_FILES because they are privacy invasive, you can view operations on all files and by all users.
A descendant client is different, if Alice creates a descendant client she will never see operations issued by Bob, in fact she will only control operations she and her descendants (and their descendants recursively) issue. The privacy concerns are not the same.
Similarly, deadline enforcement exists to break deadlocks and protect critical system daemons. Alice can only block processes she could already kill or suspend anyway. System daemons will never be a descendant and as such descendants clients can extend deadlines.
The primary use case we envision for this is agents. es_new_descendants_client() is effectively a new feature for creating dynamic sandboxes. Agents are inherently non-deterministic and subject to prompt injection attacks. Implementors need some way to control their interactions with the operating system. Using es_new_descendants_client() in combination with the new es_set_deadline_min() you can create an interactive UX for approving agent operations.
Are the reserved ES events (like the one for pasteboard) preparation for potential public use or are they solely intended for internal use?
We don't comment on future plans.
