Re: Replacing launchd
Re: Replacing launchd
- Subject: Re: Replacing launchd
- From: Graham J Lee <email@hidden>
- Date: Fri, 30 Sep 2005 21:16:31 +0100
Jordan K. Hubbard wrote:
As you yourself have noted, the tcpd utility is a good example of a
policy engine which interposes itself in between the launch criteria
("incoming request on port 21!") and access control policies that the
jobs themselves know nothing, and should know nothing, about. It
sounds like this "launchproxy" tool of yours simply needs to grow some
additional knobs and also perhaps reintroduce the notion of a scripting
language which we had at the end of Tiger but kicked out of launchd
(for good reasons). That would give the users/admins what they want
and you the abstraction layers that you want. We can't just expect
everyone to roll their own, however. That will only stand in the way
of launchd's adoption since admins don't want to do that, they just
want to get their work done.
I largely agree with you Jordan, although if the goal is to have an
intermediate policy engine between launchd and its jobs, launchproxy
isn't quite that because launchd "knows" about launchproxy, and decides
whether to invoke it (see job_start_child() in launchd.c). Compare with
the tcpd model, where xinetd (say) neither knows nor cares what tcpd is
or whether a particular request is serviced by a "real" daemon or by
tcpd. The daemon which eventually runs, e.g. telnetd, also neither
knows nor cares what tcpd is nor whether it is now running because it
was execv()d by tcpd or whatever. If an admin misconfigures tcpd then
it breaks those things the admin has chosen to invoke via tcpd, nothing
else. OTOH if the mooted über-launchproxy were misconfigured then it
would break any job which launchd - not the admin - has invoked via
launchproxy.
The way I originally implemented my change by extending the corpus of
launchd's XML keys didn't quite achieve the above "only when I want it"
aim, but only because I was thinking in perl mode - it would have been
possible to only travel the power-checking code path if such had been
requested. And as Dave correctly pointed out even it were an
independent policy choice from the PoV of an admin it certainly wasn't
from the PoV of anyone who has to maintain a launchd code tree (of which
Dave is a shining example :-) as the additional code complexity and
dependencies are passed on to launchd, not confined to the bit of code
in charge of policy.
Therefore I strongly agree with absolutely everyone, I think, except
where I disagree :-). Taking the combined paths of least surprise for
sysadmins and least pain for devs/maintainers, I'm of the opinion that a
completely independent policy engine - so more like tcpd and less like
launchproxy - is the way to go; it also would have the benefit to those
admins who aren't fully launchd'd yet that as it wouldn't care about
launchd, it could be used with init, SystemStarter, cron et al.
Cheers,
Graham.
_______________________________________________
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