Privilege separation and crash resistance

[Thomas Clement]

Hello,

I think the following architecture is recommended when a daemon needs  
to talk to an agent:
- daemon listens on privileged port
- agent is set to run at load time and checks in with the daemon to  
vends its mach port
- daemon uses the vended mach port to launch the agent on demand

However if the daemon crashes, it loses the vended mach port and is  
unable to launch the agent.
What is the recommended solution to this situation?


Regards,
Thomas
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Damien Sorresso]

On Sep 30, 2009, at 10:25 AM, Thomas Clement wrote:

> Hello,
>
> I think the following architecture is recommended when a daemon  
> needs to talk to an agent:
> - daemon listens on privileged port
> - agent is set to run at load time and checks in with the daemon to  
> vends its mach port
> - daemon uses the vended mach port to launch the agent on demand
>
> However if the daemon crashes, it loses the vended mach port and is  
> unable to launch the agent.
> What is the recommended solution to this situation?

The really, really hacky way to do this would be to use  
bootstrap_register() to place the send right in the daemon's Mach  
bootstrap so that it can look it up when it comes back. That's about  
the only thing I can think of.
--
Damien Sorresso
BSD Engineering
Apple Inc.

_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Quinn-9]

At 17:25 +0200 30/9/09, Thomas Clement wrote:
>What is the recommended solution to this situation?

I generally do this stuff with UNIX domain sockets because they are
so much easier to understand than Mach ports.  In that case, each
agent makes a connection to the daemon's listening UNIX domain
socket.  If the client crashes, the daemon hears about it because the
socket gets closed.  If the daemon crashes, the clients hear about it
because the socket gets closed.  The client should then try to open
the socket again, which will relaunch the daemon.

S+E
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Thomas Clement]

On Oct 7, 2009, at 11:33 AM, Quinn wrote:

> At 17:25 +0200 30/9/09, Thomas Clement wrote:
>> What is the recommended solution to this situation?
>
> I generally do this stuff with UNIX domain sockets because they are  
> so much easier to understand than Mach ports.  In that case, each  
> agent makes a connection to the daemon's listening UNIX domain  
> socket.  If the client crashes, the daemon hears about it because  
> the socket gets closed.  If the daemon crashes, the clients hear  
> about it because the socket gets closed.  The client should then try  
> to open the socket again, which will relaunch the daemon.

This seems to be incompatible with the idea of launching the agent on-
demand (not keeping it alive all the time).

Thomas
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Quinn-9]

At 12:08 +0200 7/10/09, Thomas Clement wrote:
>This seems to be incompatible with the idea of launching the agent
>on-demand (not keeping it alive all the time).

Indeed.  launchd is not really structured to support that.  Services
are pulled in from top to bottom.  The user logs in, which pulls in
an agent, which pulls in the daemon.  Going the other way is tricky,
and generally not recommended.

The typical solution to this problem is to have a lightweight agent
that's always running that connects up to the daemon and launches any
requested heavyweight agents in response to requests from the daemon.
This is exactly the <x-man-page://8/UserEventAgent> is all about.
Unfortunately, at least for you, the UserEventAgent plug-in mechanism
is not public.

S+E
--
Quinn "The Eskimo!"                    <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev

[Thomas Clement]

On Oct 7, 2009, at 12:53 PM, Quinn wrote:

> The typical solution to this problem is to have a lightweight agent  
> that's always running that connects up to the daemon and launches  
> any requested heavyweight agents in response to requests from the  
> daemon. This is exactly the <x-man-page://8/UserEventAgent> is all  
> about.

Yes, I agree that this architecture seems the more appropriate.

Thanks,
Thomas
_______________________________________________
launchd-dev mailing list
launchd-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev