Post not yet marked as solved
designed from day one to be a local IPC mechanism
Thanks, that makes sense.
I have yet to watch those sessions but while we're putting plugs, let me add one more that helped me better understand GCD:
Making efficient use of the libdispatch (GCD) - https://gist.github.com/tclementdev/6af616354912b0347cdf6db159c37057
Post not yet marked as solved
Regarding 1., after one week of tracing, debugging and experimenting I now understand that the scheduler deems our daemon not worthy enough to run at our usual speed during GUI session logins due to our ProcessType and our dispatch queues not being Interactive and QOS_CLASS_USER_INTERACTIVE, respectively. In hindsight this makes sense, although the terminology is somewhat misleading in the context of a daemon.
Regarding 2., how big of an issue this really is now remains to be seen. Quinn, if you're reading this, you commented - https://developer.apple.com/forums/thread/74498#218295 that
XPC is a lot faster than UNIX domains sockets
I am generally interested in how and where this increase in speed manifests (peer lookup, connection, transmission, fault notification). Also, do you know if it would, or at least believe that it could, apply to our situation, i.e. XPC being helpful?
Post not yet marked as solved
Thanks, Quinn.
trigger a deadlock by using general system services
I assume you mean in response to an ES AUTH event. We don't block on those, currently.
Your what now? Reading the above it seems like the agent is listening on the UNIX domain socket and the daemon is connecting to it. Is that right?
Yeah I might have phrased that awkwardly... You understood correctly.
Post not yet marked as solved
I don't seem to be able to edit the original post anymore, so here is an update regarding point 2:
but it also seems to occur for other session logins.
This turns out to not be verifiable in our case. (I was false-tracked by last output. It looks a lot like last does not honor the time of GUI session logout but just counts along since there remains another, silent "background" session for the given user. That session is still a mystery of its own to me, to be honest.)
At this time, I can not tell for sure if login or logout or both cause the issue and how sessions interact with each other. I am sure, however, that any such activity considerably slows our daemon process down.
Post not yet marked as solved
Thanks, Quinn, I'll give it a try. I guess you're right about the race condition, though.
Post not yet marked as solved
I just filed enhancement requests FB8447047 (officially supported API) and FB8447115 (EndpointSecurity XPC connection events) and ask everyone else interested in resolving this issue to do the same - https://developer.apple.com/bug-reporting/ in order to increase visibility at Apple.
Post not yet marked as solved
this is a very dusty corner of macOS 😂
I think we're going for the DTS ticket... 🤞
Post not yet marked as solved
Thanks, Quinn
I think you’ve found the answer to this already, namely kCGSessionOnConsoleKey. Unfortunately, that is not the case. kCGSessionOnConsoleKey will also be false for local sessions that are logged in but are not in the foreground, i.e. the user actively locked their screen or a session was moved "into background" via fast user switching. For these sessions, sessionHasGraphicAccess is also always true, so no luck to use the bit as a differentiator. I currently see no way to distinguish remote "foreground" sessions from local "background" sessions with the SecuritySession APIs.
Since you don't seem to be aware of any API we could use as a replacement, is there maybe some additional hint available if a session is in the foreground or in the background?
Edit: After thinking about this some more, there could also be remote background sessions, of course.
Post not yet marked as solved
> you can set up the preselection to reduce the chance of this problem occurring in practice.Yes, you're absolutely right. While we did observe spurious failures unrelated to event frequency (also FB6557481), we will give auditpipe another thought. In the meantime, we hope for the addition to EndpointSecurity which we prefer a lot over the auditpipe for its reliability and configurability.
Post not yet marked as solved
Thanks, Quinn!I'll admit we knew about auditpipe but ruled it our early with regards to FB6557481. However, your answer confirmed my belief that this feature should be a part of EndpointSecurity. I just filed the enhancement request FB7699856.
Thank you, Quinn!We were under the impression that the "contemporary" way to to identify a user session (from user space) was its security session ID while ASID was a more obscure construct primarily used by libbsm and, in extension, ES. But, as you put it, the state of affairs seems to be more like the opposite. Please pardon the ignorance, but what API would let us directly retrieve the ASID from user space? Our intention is to pass it on to a daemon that tracks process events back to the user session where they originated. We are aware that the ASID can be obtained from XPC connections which, of course, can also point to agents living in user space. Unfortunately, that technology is not in the picture right now.EDIT: Seems like getting the audit token for our task seems to do the job pretty well.
