site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I think the root of my recent trouble with Darwin daemons is that I expected a call to setsid() to create a new bootstrap context. However, it doesn't seem to do that. Is that a bug in Darwin? As it is, when I call fork() ==> process B setsid() ==> process group B fork() ==> process C exec() as a non-root user from a bootstrap context which is then terminated (say, an SSH login), I wind up with process C having a bad bootstrap context. There are two possible reasons for this that I can see: or 2. setsid() does create a new BC, but process B is the group leader, and the termination of B destroys the new context, so C winds up with an invalid BC. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com On Apr 3, 2009, at 3:36 PM, Terry Lambert wrote: On Apr 3, 2009, at 12:42 PM, Bill Janssen wrote: Damien Sorresso <dsorresso@apple.com> wrote: On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: Why would you expect this? Well, perhaps I'm just confused about the mapping of POSIX "session" onto Darwin. I thought the whole point of setsid() is to create a new process group that was independent of the pre-setsid process group. I'd expect it to create a new bootstrap context that would also be independent of the bootstrap context existing before setsid() was called, so that that the process group in that parent session could be terminated without affecting processes in the child session. 1. setsid() doesn't create a new bootstrap context for process group B, I'd appreciate more insight into this... POSIX sessions and launchd bootstrap sessions and Kerberos sessions and windowServer sessions and loginWindow sessions and securityd sessions and Common Criteria Auditing sessions, ..., are all orthogonal things. Expanding on this, we at Apple are just as aware of and frustrated with the utter confusion that these different notions of "sessions" generate as our external developers are. You're not alone. :) So, as a public service announcement, in the currently shipping Mac OS X (Leopard), the existing notions of sessions are as follows. • launchd bootstrap. This session type exists in a hierarchical structure. The system (i.e. PID 1) launchd provides the root bootstrap. Per-user launchd's provide sub-bootstraps for each user. Within each per-user bootstrap can be several sub-bootstraps for different entry points into the system (i.e. an "Aqua" bootstrap for graphical logins and a "StandardIO" bootstrap for SSH logins). Some processes may also call bootstrap_subset() to create sub-bootstraps for their own purposes. • WindowServer session. Very closely tied to a launchd bootstrap. WindowServer sessions are expressed by the presence of the "com.apple.WindowServer.session" MachService in a launchd bootstrap. When a client sends a message to that service port, WindowServer knows which port in its portset the message came from and assigns a session based on that. • securityd session. Very closely tied to a launchd bootstrap. securityd sessions are expressed by the presence of the "com.apple.SecurityServer" MachService in a launchd bootstrap. When a client sends a message to that service port, securityd knows which port in its portset the message came from and assigns a session based on that. • loginwindow session. This could also be described as a "graphical console session". loginwindow does a funny dance. It begins its life as a daemon in the system bootstrap, but when a user logs in, it packs up and moves itself (and its family) to the new user bootstrap that is created. So when loginwindow shows its UI, it's part of a "LoginWindow" bootstrap. After a user logs in, it becomes part of that new (per-user) bootstrap. If there are multiple users logged in at the console (i.e. through fast user-switching), there will be one loginwindow instance per console session to manage it. So if there are no users logged in, there is one loginwindow instance. If N users are logged in, there are N loginwindow instances. There are also Common Criteria auditing sessions, but those are only applicable on systems which have auditing turned on. Hope this helps. And again, sorry for all the confusion. We really do want to change it. -- Damien Sorresso BSD Engineering Apple Inc. smime.p7s