Re: should setsid() create new bootstrap context?
Re: should setsid() create new bootstrap context?
- Subject: Re: should setsid() create new bootstrap context?
- From: Damien Sorresso <email@hidden>
- Date: Fri, 03 Apr 2009 18:21:17 -0700
On Apr 3, 2009, at 3:36 PM, Terry Lambert wrote:
On Apr 3, 2009, at 12:42 PM, Bill Janssen wrote:
Damien Sorresso <email@hidden> wrote:
On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote:
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?
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.
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:
1. setsid() doesn't create a new bootstrap context for process
group B,
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.
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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden