[quote='803396022, DTS Engineer, /thread/763453?answerId=803396022#803396022'] Five Stages of Mac Screen Sharing Developer Grief [/quote] haha. Actually, I've already decided on daemon-with-zero-or-more-helper-agents architecture. The only hiccup now is I wanted the daemon to be able to enumerate sessions as well - just so it has a clear idea of system state. Seems like the only option is to get data from agents and use that in daemon.

[quote='803229022, DTS Engineer, /thread/763453?answerId=803229022#803229022'] macOS 15 (currently a release candidate) has changes such that screen sharing apps need an additional capability. [/quote] Thanks for the headsup! [quote='803229022, DTS Engineer, /thread/763453?answerId=803229022#803229022'] You have to define what you mean by “GUI Session ID”. What API are you using that works in terms of session IDs. [/quote] SessionGetInfo - Just looked at the documentation, Apple terminology is Security Session ID. Note that I'm only interested in UI sessions, so sessions that have sessionHasGraphicAccess bit set. Is there a way to enumerate all Sessions in daemon and also get their state (i.e. which one is Active)? [quote='803229022, DTS Engineer, /thread/763453?answerId=803229022#803229022'] You should explore Apple’s screen sharing features at the user level. [/quote] I guess its safe for me to assume that if someone's using my screensharing app, they won't be using Apple's built-in screen sharing feature simultaneously. So SCDynamicStoreCopyConsoleUser should be fine in my case. But it only returns username and uid, in my daemon, how can get security session id of the user from this info? Came across an example of someone using getutxent api to get list of all interactive sessions: Forum isn't letting me share url. Is this an old api? does it still work fine?

FYI, When I mention Session I always mean a UI Session (whether its prelogin or User's) - gotten used to saying just Session because of Windows. I'm working on a screen sharing app so that's why I'm interested in capturing the entire UI pre-login, lock, desktop etc. [quote='803061022, DTS Engineer, /thread/763453?answerId=803061022#803061022'] That window server session is used for all GUI work related to that login session. This includes, for example, screen saver unlock. [/quote] So login screen runs in its own GUI Session (does it get its own GUI Session ID?) and for that Pre-Login Agent is launched and it runs in the context of user _securityagent. After Login the user's GUI session is created and user gets its own Window Server. Everything relative to that User's GUI is displayed in that GUI Session i.e. normal desktop, lock screen and screensaver? [quote='803061022, DTS Engineer, /thread/763453?answerId=803061022#803061022'] For example, if you fast user switch from user A to user B, there may or may not be a pre-login session spun up in between. [/quote] Which GUI session is responsible for displaying UI in this scenario? First user A's GUI session or user B's? This question is predicated on the assumption that there’s only a single GUI login session visible on screen at a time. That’s not true. With screen sharing it’s possible to have multiple GUI login sessions active simultaneously [2]. FYI, the best way to get the current console user from a daemon is SCDynamicStoreCopyConsoleUser. AFAIK, there is only one Active GUI session possible on mac. What's the scenario in which multiple GUI login sessions are Active and displaying a UI? I looked into SCDynamicStoreCopyConsoleUser it returns username, uid, and gid. How do I get GUI session ID for the console user? (for both cases, prelogin and user session) [quote='803061022, DTS Engineer, /thread/763453?answerId=803061022#803061022'] This daemon-with-zero-or-more-helper-agents architecture has stood the test of time. [/quote] That's the approach I'm planning on taking now. My main concern with that is if a user keeps terminating one of the user agents, would the system keep restarting it? If not, my daemon would be blind to what's going on in that user's session - in terms of capturing screen etc. Also, with this approach of Pre-login & user agents doing the work. Assuming each Agent notifies daemon of the active/current session. Would the system always be in correct 'state' i.e. is there a scenario where my application would miss out on screen capture e.g. fast user switching from user A to user B, etc basically the edge cases. Would at least one Agent (pre-login or User) always be in the Active Window server to capture screen?

Thanks again for the detailed reply. I'll try out porting the existing code using thread-level impersonation and go from there.

Thanks for the detailed response! Authentication part I understood, so that's resolved. In a pure Unix environment, there isn't really any difference between "a process running as a given user" and "a process running as a given user that was created in a login session". This cleared up a lot of things, however, earlier you wrote this: pthread_setugid_np lets a process running as root shift one of it's thread identies to be a different user, at least as far as the BSD system is concerned. If you want to create a file as a different user, then it works great. If you want access to the users home directory... then it does nothing whatsoever. It changes how the system "thinks" about that particular thread but that doesn't change the larger state of other components, like the home directory not being available. Was this statement specific to pthread_setugid_np? If I'm reading this right, forking a new process won't have any limitation wrt accessing user home directory etc (excluding some edge cases) but using pthread-setugid_np would have limitation? or do these two basically have the same limitations? My current file server on windows is setup to do impersonation at thread level, so simplest option for me to port code is doing thread level impersonation on macOS as well. Should I go with pthread_setugid_np or is my only option forking a new process?

Note that in both of these example, this is a FEATURE not a bug. The system was intentionally designed so that this data would not be accessible unless the user had logged in. On windows, its doable by calling LogonUser (using user's credentials), loading user's environment and then being able to access home directory etc. Is there an equivalent flow on macOS? I'm not sure what you mean here. That API assumes you're running as a privileged user ("root"), so there isn't anything to verify. That's the reason I'm getting user credentials as well. 1. That way I can verify that the client does have the right credentials to access the files. 2. I can pass on the credentials to logon the user and then access their files. So what's the right approach for implementing a file server on macOS in which I can access files just as if the user was logged-on to the GUI terminal/console?

No worries...just filed a support request in DTS :)

Were you able to figure out the issue?

Were you able to figure out the issue?

Were you able to figure out the issue?