site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) Cheers, Graham. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. This email sent to site_archiver@lists.apple.com