Re: should setsid() create new bootstrap context?
Re: should setsid() create new bootstrap context?
- Subject: Re: should setsid() create new bootstrap context?
- From: Terry Lambert <email@hidden>
- Date: Fri, 3 Apr 2009 15:36:57 -0700
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.
Except for POSIX sessions, they are almost all either mostly or
entirely user-space constructs in the imagination of various daemons,
so it's not really reasonable to expect that a POSIX system call
interface would do anything to anything but the POSIX session.
It's unfortunate that they are all confusingly named "* session" for
historical reasons, and it's unfortunate they they weren't treated as
nested containers from the start, but a lot of these things were
developed independently over time, and replacing the word "session"
with the word "container" wouldn't be any more helpful.
Without requiring a directed acyclic hierarchical relationship between
them, however, this situation just isn't going to get resolved; _with_
requiring it, you'd basically outlaw some existing, deployed use
models, which would be a bummer if you were one of the people who
depended on one of them, and it was suddenly yanked out from under you.
-- Terry
_______________________________________________
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