Re: should setsid() create new bootstrap context?
Re: should setsid() create new bootstrap context?
- Subject: Re: should setsid() create new bootstrap context?
- From: Bill Janssen <email@hidden>
- Date: Fri, 3 Apr 2009 18:06:02 PDT
- Comments: In-reply-to Terry Lambert <email@hidden> message dated "Fri, 03 Apr 2009 15:36:57 -0700."
Terry Lambert <email@hidden> 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.
>
> 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
Well, yes, but we coped with Apple's re-write of X11, too :-).
Thanks, Terry. Perhaps I can finesse this by re-writing my daemon so
that launchd can launch it. Then, if I set the "UserName" key to the
right user, and the "KeepAlive" and "RunAtLoad" properties to "true", it
should run in the startup bootstrap context, and restart automatically
if the user kills it. Which should be close enough.
Bill
_______________________________________________
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