Re: launchd daemon, spawning children?
Re: launchd daemon, spawning children?
- Subject: Re: launchd daemon, spawning children?
- From: Damien Sorresso <email@hidden>
- Date: Fri, 26 Sep 2008 02:09:30 -0700
On Sep 26, 2008, at 12:52 AM, Mario Emmenlauer wrote:
Now this was a misunderstanding (and its probably my fault because I
didn't note it more explicit): I don't want to show GUI. Quoting
myself, my application is a workload distribution process, that is
basically similar to an ftp-daemon: user connects over network,
daemon gets user request, daemon executes K workers that process
user data. Executing the K workers is the problem I'm having now.
You mentioned LSOpenApplication() as an alternative you investigated.
So I concluded that you were interested in launching applications.
Also, for future reference, on Mac OS X, the term "application" is
generally used to refer to a process which presents a GUI. Background
processes are "daemons".
I don't need GUI (even though I wouldn't mind it, if it comes at no
additional cost). But I need access to the users data. That doesn't
enforce that the daemon is running as the specific user, a dedicated
incoming directory would do. But for security and simplicity it
seemed a good idea to setuid to the user, both for read-privileges
and also for security (not running as root if not needed).
You should not call setuid(2) and friends from a launchd daemon. The
idea of launchd is to take care of as much of the standard bookkeeping
work of writing a daemon as possible through data -- in this case, the
property list. You just have to be willing to step outside the
traditional Unix model. :)
So do I need to bootstrap user sessions for that?
It depends on what you mean by "user data". Do you mean plain text
files (or binary files in your own format) that you're just reading
from the home directory? If so, probably not.
But many APIs on Mac OS X have a launch daemon backing them. So to
you, you might just be reading an Address Book database. But behind
the scenes, a daemon might be accessing that data for you, and it
might make the decision of whose data to look up based not on the
credentials of the requestor, but what bootstrap he is in. Or possibly
both.
(That's a hypothetical example. I don't know off-hand if that's really
how Address Book works on Mac OS X.)
Your idea of per-user daemons/agents is still good, because that
would eliminate the need for the master daemon to run as root (only
root processes can setuid?).
The rules of setuid(2) have evolved into a vastly complex morass with
subtle variations on different platforms. Entire papers have been
written about this behavior.
But yes, in a launchd context, only processes running under the system
launchd can set the UserName key and expect it to be enforced. Thus,
you can only drop privileges.
It might work well in combination with launchd:
- master daemon runs as dedicated user
- upon event, master dynamically sets up launchd plist for worker
daemon for user (can a non-root process do that?)
No. See above.
- launchd starts worker daemon
- worker daemon posix_spawn's K instances, that connect to master
(Could I request launchd to start K instances?)
launchd works very hard to ensure that there is, at most, one process
running for each job in a given bootstrap.
Or I'm going back to Terry's suggestion of posix_spawning with the
correct uid, which seems safe and sound for my case too.
It all depends on what user data you need access to. If the needs are
simple (i.e. you just need the path to the home directory so you can
read and write state), then sure, posix_spawn(2) should do just fine
for you. Just make sure that your master daemon properly reaps its
children and all that jazz.
In short, if you're doing just plain Unixy stuff, you should be okay.
If you want to use any higher-level Mac OS X APIs, you might run into
problems.
--
Damien Sorresso
BSD Engineering
Apple Inc.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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