Re: testing the current bootstrap context?
Re: testing the current bootstrap context?
- Subject: Re: testing the current bootstrap context?
- From: Bill Janssen <email@hidden>
- Date: Wed, 8 Apr 2009 16:50:31 PDT
- Comments: In-reply-to Quinn <email@hidden> message dated "Wed, 08 Apr 2009 14:47:18 -0700."
Thanks, I've read those Quinn <email@hidden> wrote:
> <http://developer.apple.com/samplecode/BootstrapDump/index.html>
Yes, I've run it :-). I've mainly been using launchctl bslist, though,
which I think is less useful.
> Check out the "MAP" option.
Yes, I should have looked harder at this.
> Most problems like this are caused by folks starting their program in
> the wrong bootstrap namespace. TN2083 describes this whole process
> in gory detail. Specifically, check out the "Mach Bootstrap Basics",
> "Starting a Daemon", and "Bootstrap Namespaces: One More Thing"
> sections.
>
> <http://developer.apple.com/technotes/tn2005/tn2083.html>
Right. What I didn't understand was that even the conventional UNIX
daemonization dance of fork, setsid, fork, exec would not remove the
resulting daemon from the login bootstrap context. For some reason I
figured setsid() would put the resultant process group in the startup
context.
The only way to do this in Leopard seems to be with launchd, which seems
to do the right thing. The main problem with using launchd here is that
users cannot manipulate their own server; you can either use a root
LaunchDaemon which only root can unload, or a user LaunchDaemon which is
again fatally bound to the login bootstrap context.
For the delectation of darwin-kernel readers, here's more on this:
Subject: Re: should setsid() create new bootstrap context?
From: Damien Sorresso <email@hidden>
Date: Fri, 3 Apr 2009 18:21:17 PDT
To: Terry Lambert <email@hidden>
Cc: Bill Janssen <email@hidden>, email@hidden
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden