Privilege separation and crash resistance
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
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.
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
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
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
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
participants (3)
-
Damien Sorresso
-
Quinn
-
Thomas Clement