From huntc at internode.on.net Sun Dec 2 04:38:51 2007 From: huntc at internode.on.net (Christopher Hunt) Date: Sun Dec 2 04:35:56 2007 Subject: [launchd-dev] The mysterious SHAuthorizationRight key Message-ID: <21EE8325-F440-4B5C-9B0D-0CFAFEB34979@internode.on.net> Hi there, Running 10.5.1, I see the following in my syslog: com.apple.launchd[1] (org.apache.httpd): Unknown key: SHAuthorizationRight Upon investigating the launchd plist for httpd there is a declaration: SHAuthorizationRight system.preferences Unfortunately I have been unable to find launchd documentation describing this key. Can you please advise; I like to know what my syslog messages mean. :-) Cheers, -C From zarzycki at apple.com Mon Dec 3 10:01:16 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Mon Dec 3 10:00:20 2007 Subject: [launchd-dev] The mysterious SHAuthorizationRight key In-Reply-To: <21EE8325-F440-4B5C-9B0D-0CFAFEB34979@internode.on.net> References: <21EE8325-F440-4B5C-9B0D-0CFAFEB34979@internode.on.net> Message-ID: <4FF86381-510A-4B28-87DD-7084DD795CC9@apple.com> A project at Apple is overloading the launchd configuration file schema to store non-launchd preferences. We hope to resolve this matter in the next major version of Mac OS X. davez On Dec 2, 2007, at 4:38 AM, Christopher Hunt wrote: > Hi there, > > Running 10.5.1, I see the following in my syslog: > > com.apple.launchd[1] (org.apache.httpd): Unknown key: > SHAuthorizationRight > > Upon investigating the launchd plist for httpd there is a declaration: > > SHAuthorizationRight > system.preferences > > Unfortunately I have been unable to find launchd documentation > describing this key. Can you please advise; I like to know what my > syslog messages mean. :-) > > Cheers, > -C > _______________________________________________ > launchd-dev mailing list > launchd-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/launchd-dev From jaharmi at jaharmi.com Tue Dec 4 19:26:11 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Tue Dec 4 19:23:23 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: Message-ID: On 11/26/07 4:47 AM, "Quinn" wrote: > At 23:29 +0100 22/11/07, Louis Granboulan wrote: >> I would like to support Jeremy Reichman's request, because I >> apparently have similar needs. > > Cool. Please file a bug describing what you want to achieve: > > > > It may not be easy (or possible) to do what you want (because of > layering constraints within the system) but, once we have an official > bug report, we'll have a reason to investigate this properly. > > S+E If I haven't filed one myself, I will be doing so. And I think I have one other person from the MacEnterprise set who will, as well. -- Jeremy From jaharmi at jaharmi.com Tue Dec 4 19:39:46 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Tue Dec 4 19:36:50 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents Message-ID: This may be something of a "duh" but I'm curious if it is intentional and immutable that per-user LaunchAgents, such as those a sys admin might want to stuff into /Library/LaunchAgents, ignore the "UserName" key. In launchd.plist's man page: "UserName This optional key specifies the user to run the job as. The default is the user who submitted the job to launchd." When that key is specified in a LaunchAgent, even one in /Library/LaunchAgents, I've found that the key is ignored, a message to that effect is written to the system.log, and the job runs as the user that is logging in. Why do I want to specify it? Well, launchd tasks have certain advantages over LoginHook (and LogoutHook). If I could replace LoginHook scripts -- which, let's face it, are limited in that they have to be called by a single script parent script (similar to `/usr/sbin/periodic`) -- with launchd tasks, I'd much prefer to do so. For one thing, there's no modification of the loginwindow plist -- and the use of individual launchd jobs would make it much easier to run multiple tasks. The most obvious way to accomplish that is with a LaunchAgent, but Login|LogoutHook run as root. Hence the problem. If your LoginHook-type tasks need root access for whatever reason, then the obvious launchd way to set that up is with the UserName key in your job plist. But it doesn't work. I can see the wisdom of ignoring the key, but if a sys admin has placed a job in /Library/LaunchAgents, and that directory is installed with the system using restrictive permissions, and the job is owned by root, there would seem to be several adequate safeguards in place to make malicious use difficult. (Application Launch Restrictions are already depending on the filesystem location and permissions, at least in managed environments, so it would seem that launchd could do so as well.) I would be supportive of other reasonable safeguards besides these, too, including script signing and more. Besides asking whether ignoring the UserName key is meant to be this way and could be changed in the future if enhancement requests were filed, is there another way to replace the hooks with launchd? Thanks! -- Jeremy From launchd at khiltd.com Tue Dec 4 19:47:04 2007 From: launchd at khiltd.com (Nathan Duran) Date: Tue Dec 4 19:44:10 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <3C2FBBE6-AA64-47E6-A83D-D37577A92141@khiltd.com> On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote: > If I haven't filed one myself, I will be doing so. And I think I > have one > other person from the MacEnterprise set who will, as well. Since using an ip-up script has been known to destroy VPN connectivity (4873060) this would be a useful feature indeed. From jaharmi at jaharmi.com Tue Dec 4 19:49:14 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Tue Dec 4 19:46:21 2007 Subject: [launchd-dev] Sincere thanks about wake from sleep Message-ID: I have tested launchd jobs that were scheduled to run during sleep subsequently execute when a system is woken up. I'm happy that missed jobs do now run -- and they run immediately upon wake in Leopard. In Tiger, if the jobs ran, it was hours later. They were greatly offset from the time of system wake. This made the use of scheduled overnight jobs less useful from a systems administration perspective, and Leopard definitely improves upon that experience. Thanks! -- Jeremy From jaharmi at jaharmi.com Tue Dec 4 19:55:18 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Tue Dec 4 19:52:17 2007 Subject: [launchd-dev] Cross-job coalescing Message-ID: I haven't found a way to do this after looking over the docs (but not the new TechNote) ... I am wondering if there is a way to have two or more launchd tasks that call the same script coalesce into the same event during events like wake from sleep. For example, what if the same script is called by both a nightly job, and a weekly job? Are the various instances of the jobs that would have run automatically then coalesced into one instance if their scheduled execution is missed? Or, if not, is there a way to have some other cross-job identifier that is shared by multiple launchd jobs so that the same target script is not run more than once? TIA. -- Jeremy From jaharmi at jaharmi.com Tue Dec 4 20:01:16 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Tue Dec 4 19:58:22 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: <3C2FBBE6-AA64-47E6-A83D-D37577A92141@khiltd.com> Message-ID: On 12/4/07 10:47 PM, "Nathan Duran" wrote: > > On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote: > >> If I haven't filed one myself, I will be doing so. And I think I >> have one >> other person from the MacEnterprise set who will, as well. > > Since using an ip-up script has been known to destroy VPN connectivity > (4873060) this would be a useful feature indeed. Since Kicker.xml seems to be no more, it would potentially be useful to have launchd jobs be able to fire for almost any arbitrary SystemConfiguration change. I'm sure there is a possibility of using that for evil, so I'd want to guard against that as much as possible. Using launchd for this would also make the configuration much more granular for sys admins: just drop your script and your launchd plist onto the target computer in a launchd directory, and your job is all set to go when loaded. Compare that to editing Kicker.xml in Tiger, which was a Apple-supplied file in the System domain ... -- Jeremy From launchd at khiltd.com Tue Dec 4 20:46:08 2007 From: launchd at khiltd.com (Nathan Duran) Date: Tue Dec 4 20:43:11 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote: > it would potentially be useful to have > launchd jobs be able to fire for almost any arbitrary > SystemConfiguration > change Well since you *can* register for almost any arbitrary SC change, it wouldn't take much to whip something up that would invoke launchctl on your behalf without any direct support from Apple, though that would mean running yet another process (or two if it needed admin privileges). I can't remember if I tried doing this or not at this point, but it seems like it should work. From kvv at apple.com Wed Dec 5 00:48:37 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 00:46:24 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: References: Message-ID: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> On Dec 4, 2007, at 7:39 PM, Jeremy Reichman wrote: > This may be something of a "duh" but I'm curious if it is > intentional and > immutable that per-user LaunchAgents, such as those a sys admin > might want > to stuff into /Library/LaunchAgents, ignore the "UserName" key. Yes, it's intentional. LaunchAgents are executed by the per-user launchd. As a non-root process, it does not have the privilege to setuid(2) to another user, hence the UserName key is ignored. > In launchd.plist's man page: > > "UserName > This optional key specifies the user to run the job as. The default > is the > user who submitted the job to launchd." This was written before the advent of the per-user launchd. It should be revised to indicate this key is honored by the root launchd only (for use by LaunchDaemons). > Why do I want to specify it? Well, launchd tasks have certain > advantages > over LoginHook (and LogoutHook). If I could replace LoginHook > scripts -- > which, let's face it, are limited in that they have to be called by > a single > script parent script (similar to `/usr/sbin/periodic`) -- with launchd > tasks, I'd much prefer to do so. For one thing, there's no > modification of > the loginwindow plist -- and the use of individual launchd jobs > would make > it much easier to run multiple tasks. > > The most obvious way to accomplish that is with a LaunchAgent, but > Login|LogoutHook run as root. Hence the problem. If your LoginHook- > type > tasks need root access for whatever reason, then the obvious launchd > way to > set that up is with the UserName key in your job plist. But it > doesn't work. > > I can see the wisdom of ignoring the key, but if a sys admin has > placed a > job in /Library/LaunchAgents, and that directory is installed with the > system using restrictive permissions, and the job is owned by root, > there > would seem to be several adequate safeguards in place to make > malicious use > difficult. (Application Launch Restrictions are already depending on > the > filesystem location and permissions, at least in managed > environments, so it > would seem that launchd could do so as well.) I would be supportive > of other > reasonable safeguards besides these, too, including script signing > and more. > > Besides asking whether ignoring the UserName key is meant to be this > way and > could be changed in the future if enhancement requests were filed, > is there > another way to replace the hooks with launchd? Let's step back to a time before launchd and consider the case of an ordinary Cocoa application that needs to perform a privileged operation. Since there's no "UserName" key available in the Info.plist, the application must invoke a privileged helper tool (setuid binary, gated by AuthorizationExecWithPrivilege). With launchd, it's now possible to get rid of the setuid binary (which avoids a whole class of potential privilege escalation vulnerabilities) and replace it with a LaunchDaemon that executes in a privileged context. The Cocoa application can send an IPC message to the Daemon, and the daemon can perform the privileged operation (Authorization API can still be used to create an "external form" that can be validated across the IPC channel). A LaunchAgent, like the Cocoa application example, runs as the user -- in fact they're running in the same context. If it needs to perform a privileged operation, it can send an IPC message to a LaunchDaemon running in a privileged context to perform said operation. - Kevin From kvv at apple.com Wed Dec 5 00:58:45 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 00:57:04 2007 Subject: [launchd-dev] Cross-job coalescing In-Reply-To: References: Message-ID: <26C5364D-50F5-40BA-B8B1-8576913D504A@apple.com> On Dec 4, 2007, at 7:55 PM, Jeremy Reichman wrote: > I haven't found a way to do this after looking over the docs (but > not the > new TechNote) ... I am wondering if there is a way to have two or more > launchd tasks that call the same script coalesce into the same event > during > events like wake from sleep. > > For example, what if the same script is called by both a nightly > job, and a > weekly job? Are the various instances of the jobs that would have run > automatically then coalesced into one instance if their scheduled > execution > is missed? > > Or, if not, is there a way to have some other cross-job identifier > that is > shared by multiple launchd jobs so that the same target script is > not run > more than once? Launchd does not run multiple instances of the same job. Instead each of the criteria listed in the launchd plist is a reason to start the job only if the job is not already running. StartCalendarInterval supports an array of dictionaries -- you could specify both a nightly time and a weekly time in the same plist, either one of which will cause the job to be run, but not twice when the nightly and weekly times coincide. - Kevin From kvv at apple.com Wed Dec 5 01:02:39 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 01:00:57 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <99F5695D-4BDF-40A9-ABDA-C73C2977837F@apple.com> On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote: > On 12/4/07 10:47 PM, "Nathan Duran" wrote: >> On Dec 4, 2007, at 7:26 PM, Jeremy Reichman wrote: >> >>> If I haven't filed one myself, I will be doing so. And I think I >>> have one >>> other person from the MacEnterprise set who will, as well. >> >> Since using an ip-up script has been known to destroy VPN >> connectivity >> (4873060) this would be a useful feature indeed. > > Since Kicker.xml seems to be no more, it would potentially be useful > to have > launchd jobs be able to fire for almost any arbitrary > SystemConfiguration > change. I'm sure there is a possibility of using that for evil, so > I'd want > to guard against that as much as possible. > > Using launchd for this would also make the configuration much more > granular > for sys admins: just drop your script and your launchd plist onto > the target > computer in a launchd directory, and your job is all set to go when > loaded. > Compare that to editing Kicker.xml in Tiger, which was a Apple- > supplied file > in the System domain ... I agree this would be a very useful feature, but there are subtleties that complicate the implementation of what seems like a straightforward idea (for example, Launchd cannot be a direct client of SystemConfiguration without fear of deadlock as SystemConfiguration talks to the launchd-managed daemon configd). Nevertheless, we are exploring ways to broaden the set of events that can be specified in a launchd plist. - Kevin From kvv at apple.com Wed Dec 5 01:03:48 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 01:02:05 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References:

Message-ID: <17A8E942-4A6D-4944-94B1-98B7C85BBBB5@apple.com> On Dec 4, 2007, at 8:46 PM, Nathan Duran wrote: > > On Dec 4, 2007, at 8:01 PM, Jeremy Reichman wrote: > >> it would potentially be useful to have >> launchd jobs be able to fire for almost any arbitrary >> SystemConfiguration >> change > > Well since you *can* register for almost any arbitrary SC change, it > wouldn't take much to whip something up that would invoke launchctl > on your behalf without any direct support from Apple, though that > would mean running yet another process (or two if it needed admin > privileges). I can't remember if I tried doing this or not at this > point, but it seems like it should work. This is probably the most pragmatic solution for deployment on Leopard. - Kevin From jaharmi at jaharmi.com Wed Dec 5 06:59:29 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Wed Dec 5 07:00:03 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> Message-ID: I can understand the desire/need for privilege separation. Not being skilled in IPC, though, is there a way that systems administrators operating at a scripting level can set up what you've described? The reality is that LoginHook/LogoutHook exist today and do what I want, but I'd rather be doing the same thing with launchd because it gives me a little more granularity in setup and control. Instead of editing loginwindow.plist for root and having a hook script that does its work itself or calls other scripts to do work during those system events, I would like to have the benefit of setting up multiple compartmentalized, modularized launchd jobs. This is especially true if you manage systems with Radmind, which works really well at managing files. But moving to launchd jobs for what would have been in Login/LogoutHook also seems to make sense for the more installer-based management provided by ARD, LanDesk, LANrev, FileWave, etc. Thanks! -- Jeremy From jaharmi at jaharmi.com Wed Dec 5 07:02:13 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Wed Dec 5 07:00:04 2007 Subject: [launchd-dev] Cross-job coalescing In-Reply-To: <26C5364D-50F5-40BA-B8B1-8576913D504A@apple.com> Message-ID: On 12/5/07 3:58 AM, "Kevin Van Vechten" wrote: > Launchd does not run multiple instances of the same job. Instead each > of the criteria listed in the launchd plist is a reason to start the > job only if the job is not already running. > > StartCalendarInterval supports an array of dictionaries -- you could > specify both a nightly time and a weekly time in the same plist, > either one of which will cause the job to be run, but not twice when > the nightly and weekly times coincide. I've thought about having multiple schedules, but haven't tried it. What about mixing a StartCalendarInterval with StartInterval? Or any of the *Interval keys with WatchPaths or QueueDirectories? Can that also be done, and if so are their differences between Tiger and Leopard? Just curious. Thanks! -- Jeremy From jaharmi at jaharmi.com Wed Dec 5 07:04:39 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Wed Dec 5 07:01:29 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: <99F5695D-4BDF-40A9-ABDA-C73C2977837F@apple.com> Message-ID: On 12/5/07 4:02 AM, "Kevin Van Vechten" wrote: > I agree this would be a very useful feature, but there are subtleties > that complicate the implementation of what seems like a > straightforward idea (for example, Launchd cannot be a direct client > of SystemConfiguration without fear of deadlock as SystemConfiguration > talks to the launchd-managed daemon configd). Nevertheless, we are > exploring ways to broaden the set of events that can be specified in a > launchd plist. I would be just as happy if there were a file that was consistently and reliably modified during network changes, so that the WatchPaths key could be used. I'm not aware of such a file and past discussions about this on the MacEnterprise list haven't turned one up (to my recollection), but that doesn't mean it doesn't exist. -- Jeremy From zarzycki at apple.com Wed Dec 5 08:53:02 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Wed Dec 5 08:50:46 2007 Subject: [launchd-dev] Cross-job coalescing In-Reply-To: References: Message-ID: <5325AB95-86E9-4C72-B854-4394F891C476@apple.com> On Dec 5, 2007, at 7:02 AM, Jeremy Reichman wrote: > On 12/5/07 3:58 AM, "Kevin Van Vechten" wrote: > >> Launchd does not run multiple instances of the same job. Instead >> each >> of the criteria listed in the launchd plist is a reason to start the >> job only if the job is not already running. >> >> StartCalendarInterval supports an array of dictionaries -- you could >> specify both a nightly time and a weekly time in the same plist, >> either one of which will cause the job to be run, but not twice when >> the nightly and weekly times coincide. > > I've thought about having multiple schedules, but haven't tried it. > > What about mixing a StartCalendarInterval with StartInterval? Or any > of the > *Interval keys with WatchPaths or QueueDirectories? Can that also be > done, > and if so are their differences between Tiger and Leopard? Just > curious. Launchd logically ORs all criteria. The differences between Tiger and Leopard can be vast or inconsequential depending on your perspective. The single largest "features" that launchd added were: 1) per-user/per-session launchd magic. 2) Mach support 3) Conditional KeepAlive logic. davez From zarzycki at apple.com Wed Dec 5 09:09:19 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Wed Dec 5 09:07:32 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <6DEBECA5-A393-4A28-B7EE-3B63536E538B@apple.com> On Dec 5, 2007, at 7:04 AM, Jeremy Reichman wrote: > On 12/5/07 4:02 AM, "Kevin Van Vechten" wrote: > >> I agree this would be a very useful feature, but there are subtleties >> that complicate the implementation of what seems like a >> straightforward idea (for example, Launchd cannot be a direct client >> of SystemConfiguration without fear of deadlock as >> SystemConfiguration >> talks to the launchd-managed daemon configd). Nevertheless, we are >> exploring ways to broaden the set of events that can be specified >> in a >> launchd plist. > > I would be just as happy if there were a file that was consistently > and > reliably modified during network changes, so that the WatchPaths key > could > be used. I'm not aware of such a file and past discussions about > this on the > MacEnterprise list haven't turned one up (to my recollection), but > that > doesn't mean it doesn't exist. The problem is that "network changed" is vague. It means different things to different people. Does it include updates to the list of DNS servers? Does it include updates to the DNS database? What about when the default route changes? What about if any route is added or deleted? What about when interfaces go on and offline? What about when interfaces are added or removed? What about when the computer switches between wireless base stations? What about when the computer updates the IP address(es) assigned to an interface? Does network change notification include explicit testing for the presence or absence of a given node? Does it include updates to proxy configuration details? Does it include updates to the list of LDAP servers the machine is using? Does it include updates to the list of Kerberos servers being used? What about when the ARP table updates? One can easily make "slippery-slope" arguments towards the "network change" notification firing continuously? As a consequence of both real and contrived examples, we frequently advise that developers write a program to use the System Configuration framework to directly narrow down the criteria that they are specifically interested in. *shrug* davez From zarzycki at apple.com Wed Dec 5 09:15:46 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Wed Dec 5 09:13:30 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: References: Message-ID: <5FD33A6B-DB3A-4115-B33E-FEAA73E83A7E@apple.com> On Dec 5, 2007, at 6:59 AM, Jeremy Reichman wrote: > I can understand the desire/need for privilege separation. > > Not being skilled in IPC, though, is there a way that systems > administrators > operating at a scripting level can set up what you've described? Not really. That is a sore spot in the operating system right now. Actually, scripting in general is a sore spot of most, if not all, operating systems, given that the core routines tend to be written in compiled languages first, and those routines are NOT automatically bridged to the interpreted languages. > The reality is that LoginHook/LogoutHook exist today and do what I > want, but > I'd rather be doing the same thing with launchd because it gives me > a little > more granularity in setup and control. Instead of editing > loginwindow.plist > for root and having a hook script that does its work itself or calls > other > scripts to do work during those system events, I would like to have > the > benefit of setting up multiple compartmentalized, modularized > launchd jobs. Setup a launchd job that launches at login. Have it do the LoginHook stuff you used to do. Then have the program wait for SIGTERM. Once SIGTERM arrives, do the LogoutHook stuff and exit. davez From zarzycki at apple.com Wed Dec 5 09:24:13 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Wed Dec 5 09:22:27 2007 Subject: [launchd-dev] Sincere thanks about wake from sleep In-Reply-To: References: Message-ID: On Dec 4, 2007, at 7:49 PM, Jeremy Reichman wrote: > I have tested launchd jobs that were scheduled to run during sleep > subsequently execute when a system is woken up. I'm happy that > missed jobs > do now run -- and they run immediately upon wake in Leopard. > > In Tiger, if the jobs ran, it was hours later. They were greatly > offset from > the time of system wake. This made the use of scheduled overnight > jobs less > useful from a systems administration perspective, and Leopard > definitely > improves upon that experience. You're welcome. Thanks for noticing. :-) davez From launchd at khiltd.com Wed Dec 5 09:31:02 2007 From: launchd at khiltd.com (Nathan Duran) Date: Wed Dec 5 09:27:49 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> Message-ID: <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> On Dec 5, 2007, at 12:48 AM, Kevin Van Vechten wrote: > With launchd, it's now possible to get rid of the setuid binary > (which avoids a whole class of potential privilege escalation > vulnerabilities) and replace it with a LaunchDaemon that executes in > a privileged context. The Cocoa application can send an IPC message > to the Daemon, and the daemon can perform the privileged operation > (Authorization API can still be used to create an "external form" > that can be validated across the IPC channel). I'm afraid I don't understand what is meant by the term "external form" here. Are you suggesting that the authorization API be used to prevent rogue applications from utilizing the IPC services vended by the daemon? From subscriber at gloaming.com Wed Dec 5 09:38:38 2007 From: subscriber at gloaming.com (James Bucanek) Date: Wed Dec 5 09:35:25 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> Message-ID: Nathan Duran wrote (Wednesday, December 5, 2007 10:31 AM -0800): >I'm afraid I don't understand what is meant by the term "external >form" here. Are you suggesting that the authorization API be used to >prevent rogue applications from utilizing the IPC services vended by >the daemon? Hey, a question I can answer. :) When you authenticate a user, you get an authorization reference which can then be passed to various Authorization API functions to do stuff. However, authorization references cannot be passed between processes. To obtain an authorization (like in a GUI app) and pass that to another process for it to use (like a deamon or faceless helper) you must convert the authorization ref into an "external form", which is just an opaque data blob that encapsulates the authorization. You then pass that data blob to the other process, which then turns the "external" form of the authorization back into a usable authorization ref. -- James Bucanek From kvv at apple.com Wed Dec 5 09:46:03 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 09:44:19 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> Message-ID: On Dec 5, 2007, at 9:31 AM, Nathan Duran wrote: > On Dec 5, 2007, at 12:48 AM, Kevin Van Vechten wrote: > >> With launchd, it's now possible to get rid of the setuid binary >> (which avoids a whole class of potential privilege escalation >> vulnerabilities) and replace it with a LaunchDaemon that executes >> in a privileged context. The Cocoa application can send an IPC >> message to the Daemon, and the daemon can perform the privileged >> operation (Authorization API can still be used to create an >> "external form" that can be validated across the IPC channel). > > I'm afraid I don't understand what is meant by the term "external > form" here. Are you suggesting that the authorization API be used to > prevent rogue applications from utilizing the IPC services vended by > the daemon? The term "external form" is just taken from the relevant Authorization API -- AuthorizationMakeExternalForm(...). Depending on the context of the privileged operation, yes, it makes sense to vet incoming IPC requests with the Authorization API before performing the operation. For example, we have a launch-on-demand helper that performs some privileged operations on behalf of System Preferences.app; but it only performs the operation if the "system.preferences" right has been acquired (via clicking the lock icon in System Preferences). - Kevin From eskimo1 at apple.com Wed Dec 5 09:51:23 2007 From: eskimo1 at apple.com (Quinn) Date: Wed Dec 5 09:54:39 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> Message-ID: At 9:31 -0800 5/12/07, Nathan Duran wrote: >I'm afraid I don't understand what is meant by the term "external >form" here. Are you suggesting that the authorization API be used to >prevent rogue applications from utilizing the IPC services vended by >the daemon? For a concrete illustration of this, check out the recently released BetterAuthorizationSample. Share and Enjoy -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From launchd at khiltd.com Wed Dec 5 10:11:41 2007 From: launchd at khiltd.com (Nathan Duran) Date: Wed Dec 5 10:08:28 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> Message-ID: <50D21E68-A3E8-4EC2-BB2C-394380423541@khiltd.com> On Dec 5, 2007, at 9:46 AM, Kevin Van Vechten wrote: > The term "external form" is just taken from the relevant > Authorization API -- AuthorizationMakeExternalForm(...). Ah, now I remember. That's one of those APIs whose very nature encourages code recycling and I know haven't actually looked at its documentation since the last time it was updated. So if you still have to present the user with an authentication dialog then, from *their* point of view, is there any difference between the two methodologies (helper tool vs. daemons-on-demand)? On Dec 5, 2007, at 9:51 AM, Quinn wrote: > For a concrete illustration of this, check out the recently released > BetterAuthorizationSample. > > > Excellent. If I recall correctly, the fact that the previous incarnation of sample code (MoreAuth?) either didn't work or wouldn't compile factored heavily in my reluctance to revisit the API ;) I'll definitely take a look at the new stuff. From jaharmi at jaharmi.com Wed Dec 5 10:50:54 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Wed Dec 5 10:47:47 2007 Subject: [launchd-dev] Thanks for the WatchPath behavior change Message-ID: I've also noticed, in the theme of being thankful for changes in Leopard, that the behavior for the WatchPath key is different. I believe that change is for the better. In Leopard, both creating and deleting the watched path results in any job waiting for its modification to fire. This is great -- in Tiger, my experience was that the path always had to exist and that made WatchPath more limited and less useful. One question though: since removing the path also runs the job, is there a way to avoid that specific behavior? To only have the job run if the path is created or is modified in place (without deletion)? I know that that case is probably one where the QueueDirectory key should be used instead, but I figured I'd ask. Again, thanks! -- Jeremy From launchd at khiltd.com Wed Dec 5 10:54:37 2007 From: launchd at khiltd.com (Nathan Duran) Date: Wed Dec 5 11:06:52 2007 Subject: [launchd-dev] Thanks for the WatchPath behavior change In-Reply-To: References: Message-ID: <98B7544C-B84D-4A93-AEC7-7B38B574C5CC@khiltd.com> On Dec 5, 2007, at 10:50 AM, Jeremy Reichman wrote: > One question though: since removing the path also runs the job, is > there a > way to avoid that specific behavior? To only have the job run if the > path is > created or is modified in place (without deletion)? I know that that > case is > probably one where the QueueDirectory key should be used instead, > but I > figured I'd ask. Don't know the answer to that, but it'd be simple enough (and in all likelihood highly advisable) to throw a quick sanity check at the top of the script that immediately exits if whatever it needs isn't there. From zarzycki at apple.com Wed Dec 5 12:44:50 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Wed Dec 5 12:43:03 2007 Subject: [launchd-dev] Thanks for the WatchPath behavior change In-Reply-To: <98B7544C-B84D-4A93-AEC7-7B38B574C5CC@khiltd.com> References: <98B7544C-B84D-4A93-AEC7-7B38B574C5CC@khiltd.com> Message-ID: <1F681347-E2EE-4339-AC52-87A87C5AD10E@apple.com> On Dec 5, 2007, at 10:54 AM, Nathan Duran wrote: > > On Dec 5, 2007, at 10:50 AM, Jeremy Reichman wrote: > >> One question though: since removing the path also runs the job, is >> there a >> way to avoid that specific behavior? To only have the job run if >> the path is >> created or is modified in place (without deletion)? I know that >> that case is >> probably one where the QueueDirectory key should be used instead, >> but I >> figured I'd ask. > > Don't know the answer to that, but it'd be simple enough (and in all > likelihood highly advisable) to throw a quick sanity check at the > top of the script that immediately exits if whatever it needs isn't > there. I'd agree with Nathan. That is the best thing you can do for Leopard. We might fix that in a future release. davez From kvv at apple.com Wed Dec 5 14:50:27 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 14:51:33 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <50D21E68-A3E8-4EC2-BB2C-394380423541@khiltd.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> <50D21E68-A3E8-4EC2-BB2C-394380423541@khiltd.com> Message-ID: <7D352C57-4EC5-444F-BB4F-BB1E5B4BF536@apple.com> On Dec 5, 2007, at 10:11 AM, Nathan Duran wrote: > On Dec 5, 2007, at 9:46 AM, Kevin Van Vechten wrote: > >> The term "external form" is just taken from the relevant >> Authorization API -- AuthorizationMakeExternalForm(...). > > Ah, now I remember. That's one of those APIs whose very nature > encourages code recycling and I know haven't actually looked at its > documentation since the last time it was updated. > > So if you still have to present the user with an authentication > dialog then, from *their* point of view, is there any difference > between the two methodologies (helper tool vs. daemons-on-demand)? Absolutely. Helper tools require a setuid executable bit to be set; they're also inherently less secure -- every environment variable used by every library linked against is a potential source of attack. Launch-on-demand helpers start from a clean environment, avoiding this class of vulnerabilities. Additionally setuid executable binaries get in the way of drag- installs. Today, launch-on-demand helpers present the same obstacles to drag-installs because we'd recommend secure ownership (root:wheel); however this is a matter of policy (permissions are used to establish trust), not mechanism (setuid is required to escalate privilege). As we move to better mechanisms for establishing trust (code signing), we can eventually alleviate the ownership requirements and allow for drag installs. We're clearly not there yet, but moving to launch-on-demand is a step in this direction. - Kevin From launchd at khiltd.com Wed Dec 5 17:02:31 2007 From: launchd at khiltd.com (Nathan Duran) Date: Wed Dec 5 17:02:36 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <7D352C57-4EC5-444F-BB4F-BB1E5B4BF536@apple.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> <50D21E68-A3E8-4EC2-BB2C-394380423541@khiltd.com> <7D352C57-4EC5-444F-BB4F-BB1E5B4BF536@apple.com> Message-ID: <48E510F1-1C07-456C-A97C-5B3695F678FA@khiltd.com> On Dec 5, 2007, at 2:50 PM, Kevin Van Vechten wrote: > Absolutely. Helper tools require a setuid executable bit to be set; > they're also inherently less secure -- every environment variable > used by every library linked against is a potential source of > attack. Launch-on-demand helpers start from a clean environment, > avoiding this class of vulnerabilities. I get that, but I'm talking about what the user sees on their screen, not the under-the-hood stuff they know nothing about. From kvv at apple.com Wed Dec 5 18:49:02 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Wed Dec 5 18:50:35 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: <48E510F1-1C07-456C-A97C-5B3695F678FA@khiltd.com> References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> <50D21E68-A3E8-4EC2-BB2C-394380423541@khiltd.com> <7D352C57-4EC5-444F-BB4F-BB1E5B4BF536@apple.com> <48E510F1-1C07-456C-A97C-5B3695F678FA@khiltd.com> Message-ID: On Dec 5, 2007, at 5:02 PM, Nathan Duran wrote: > On Dec 5, 2007, at 2:50 PM, Kevin Van Vechten wrote: > >> Absolutely. Helper tools require a setuid executable bit to be >> set; they're also inherently less secure -- every environment >> variable used by every library linked against is a potential source >> of attack. Launch-on-demand helpers start from a clean >> environment, avoiding this class of vulnerabilities. > > I get that, but I'm talking about what the user sees on their > screen, not the under-the-hood stuff they know nothing about. I believe the dialog presented is the same in both cases. - Kevin From Louis.Granboulan at free.fr Wed Dec 5 22:19:52 2007 From: Louis.Granboulan at free.fr (Louis Granboulan) Date: Wed Dec 5 22:19:46 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <4DA56D09-21CB-4F44-AEF6-CDBAD354825F@free.fr> Le 26 nov. 07 ? 10:47, Quinn a ?crit : > At 23:29 +0100 22/11/07, Louis Granboulan wrote: >> I would like to support Jeremy Reichman's request, because I >> apparently have similar needs. > > Cool. Please file a bug describing what you want to achieve: > > > > It may not be easy (or possible) to do what you want (because of > layering constraints within the system) but, once we have an > official bug report, we'll have a reason to investigate this properly. > > S+E > -- > Quinn "The Eskimo!" developer/> > Apple Developer Relations, Developer Technical Support, Core OS/ > Hardware Here is the answer I received: > In practice, the number of event sources a "StartOnNetwork" feature > would entail is so large that we recommend developers to write a > program and use the System Configuration framework to directly > monitor the multitude of network status changes. > > We consider this issue closed. Thank you for taking the time to > notify us of this issue. Therefore, I might need some help to write that program which monitors the network status changes... Regards, Louis From marczak at radiotope.com Wed Dec 5 22:57:50 2007 From: marczak at radiotope.com (Edward R. Marczak) Date: Wed Dec 5 22:57:55 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: On Dec 5, 2007, at 10:04 AM, Jeremy Reichman wrote: > I would be just as happy if there were a file that was consistently > and > reliably modified during network changes, so that the WatchPaths key > could > be used. I'm not aware of such a file and past discussions about > this on the > MacEnterprise list haven't turned one up (to my recollection), but > that > doesn't mean it doesn't exist. How about /Library/Preferences/SystemConfiguration/preferences.plist ? -- Edward R. Marczak e: marczak@radiotope.com w: http://www.radiotope.com b: http://www.radiotope.com/writing -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2425 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071206/d7098855/smime.bin From eskimo1 at apple.com Thu Dec 6 01:23:44 2007 From: eskimo1 at apple.com (Quinn) Date: Thu Dec 6 01:31:40 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References:

Message-ID: At 1:57 -0500 6/12/07, Edward R. Marczak wrote: >How about /Library/Preferences/SystemConfiguration/preferences.plist That changes when the network /preferences/ change, not when the network state changes. For example, if someone plugs or unplugs the Ethernet, this file won't change. What /does/ change is the System Configuration framework "dynamic store". However, I don't know of any good way to hook into the dynamic store from a script. OTOH, it's trivial to do this from C code. S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From jaharmi at jaharmi.com Thu Dec 6 06:17:22 2007 From: jaharmi at jaharmi.com (Jeremy Reichman) Date: Thu Dec 6 06:17:29 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: Message-ID: On 12/6/07 4:23 AM, "Quinn" wrote: > At 1:57 -0500 6/12/07, Edward R. Marczak wrote: >> How about /Library/Preferences/SystemConfiguration/preferences.plist > > That changes when the network /preferences/ change, not when the > network state changes. For example, if someone plugs or unplugs the > Ethernet, this file won't change. > > What /does/ change is the System Configuration framework "dynamic > store". However, I don't know of any good way to hook into the > dynamic store from a script. OTOH, it's trivial to do this from C > code. I believe this was more or less the gist, minus the C code bit, of this topic on the MacEnterprise list. We couldn't find a file that always worked, so Kicker.xml (despite being in the System domain) seemed the option closest to the action. But, being in the System domain in Tiger, there was reluctance to edit it, and being gone in Leopard makes it a moot point. What about a future launchd that could monitor for changes to SystemConfiguration? What if I could supply a dictionary of paths/keys (i.e. "State:/Network/Global/IPv4" which I can see when I use "list" with scutil) I care about, and if any of them are modified, the job fires? It seems like this could also let me tap into other events I care about, like maybe even wake/sleep. Nathan said, "Well since you *can* register for almost any arbitrary SC change ... [snip]," so I'm just hoping launchd can register for me and I can edit a plist become a developer. I'm just trying to lower the bar to make this possible. I may be clearly flailing here, but I'm still curious. And I'll be filing my requests if I haven't done already so. :) -- Jeremy From marczak at radiotope.com Thu Dec 6 06:28:59 2007 From: marczak at radiotope.com (Edward R. Marczak) Date: Thu Dec 6 06:29:01 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References:

Message-ID: <993CCDDA-07FA-448C-AD18-9E47481BB5C6@radiotope.com> On Dec 6, 2007, at 4:23 AM, Quinn wrote: > At 1:57 -0500 6/12/07, Edward R. Marczak wrote: >> How about /Library/Preferences/SystemConfiguration/preferences.plist > > That changes when the network /preferences/ change, not when the > network state changes. For example, if someone plugs or unplugs the > Ethernet, this file won't change. Got it. I was basing this on Airport on/off which, in some situations is good enough for me. That updates preferences.plist and can fire a script. Thanks. -- Edward R. Marczak e: marczak@radiotope.com w: http://www.radiotope.com b: http://www.radiotope.com/writing -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2425 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071206/6f5013ae/smime-0001.bin From launchd at khiltd.com Thu Dec 6 09:24:53 2007 From: launchd at khiltd.com (Nathan Duran) Date: Thu Dec 6 09:24:55 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: <4636917A-A428-4674-86BE-C910E45423BC@khiltd.com> On Dec 6, 2007, at 6:17 AM, Jeremy Reichman wrote: > What about a future launchd that could monitor for changes to > SystemConfiguration? As has already been stated, doing so would introduce cyclical dependencies and potential deadlock conditions whereby launchd and SC were both waiting for the other to do something neither one ever would. Your computer would cease working at that point. It just isn't going to happen without some coding. From subscriber at gloaming.com Sun Dec 9 08:38:01 2007 From: subscriber at gloaming.com (James Bucanek) Date: Sun Dec 9 08:37:57 2007 Subject: [launchd-dev] Configurion a Cocoa app as a user agent Message-ID: Greetings, I have a Login Item that I'd like to replace with a ~/Library/LaunchAgent. It's a LSUIElement=YES Cocoa application. What should the executable path be? If I set it to the bundle folder, is launchd smart enough to figure out that its an application? Or do I need to set it to .../MyApp.app/Contents/MacOS/MyApp? I ask because I've been warned by the Cocoa engineers to avoid starting applications that way. -- James Bucanek From eskimo1 at apple.com Mon Dec 10 01:18:41 2007 From: eskimo1 at apple.com (Quinn) Date: Mon Dec 10 01:21:47 2007 Subject: [launchd-dev] Configurion a Cocoa app as a user agent In-Reply-To: References: Message-ID: At 9:38 -0700 9/12/07, James Bucanek wrote: >What should the executable path be? If I set it to the bundle >folder, is launchd smart enough to figure out that its an >application? Or do I need to set it to >.../MyApp.app/Contents/MacOS/MyApp? It has to point to the executable on disk; the bundle will not work. >I ask because I've been warned by the Cocoa engineers to avoid >starting applications that way. Really? Any explanation as to why? S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From subscriber at gloaming.com Mon Dec 10 08:02:56 2007 From: subscriber at gloaming.com (James Bucanek) Date: Mon Dec 10 08:02:43 2007 Subject: [launchd-dev] Configurion a Cocoa app as a user agent In-Reply-To: Message-ID: Quinn wrote (Monday, December 10, 2007 2:18 AM -0000): >At 9:38 -0700 9/12/07, James Bucanek wrote: >>What should the executable path be? If I set it to the bundle >>folder, is launchd smart enough to figure out that its an >>application? Or do I need to set it to .../MyApp.app/Contents/MacOS/MyApp? > >It has to point to the executable on disk; the bundle will not work. That's kind of what I thought. >>I ask because I've been warned by the Cocoa engineers to avoid >>starting applications that way. > >Really? Any explanation as to why? This was back in 10.3, but it went something along the lines of "the bundle structure of applications might change in the future; the recommended method is to use Launch Services ..." -- James Bucanek From eskimo1 at apple.com Mon Dec 10 08:12:07 2007 From: eskimo1 at apple.com (Quinn) Date: Mon Dec 10 08:19:57 2007 Subject: [launchd-dev] Configurion a Cocoa app as a user agent In-Reply-To: References: Message-ID: At 9:02 -0700 10/12/07, James Bucanek wrote: >This was back in 10.3, but it went something along the lines of "the >bundle structure of applications might change in the future; the >recommended method is to use Launch Services ..." In general, that's good advice. In this particular case, it's reasonable to hard-code the bundle structure. After all, you control the agent. If, in some future world, the agent's bundle changes layout, you could change the property list to match. S+E -- Quinn "The Eskimo!" Apple Developer Relations, Developer Technical Support, Core OS/Hardware From bobkells at steelcape.com Mon Dec 10 17:46:02 2007 From: bobkells at steelcape.com (bob kells) Date: Tue Dec 11 12:49:45 2007 Subject: [launchd-dev] launch cocoa-app (with gui) from launchd Message-ID: <14265985.post@talk.nabble.com> I have been unsuccessful so far attempting to launch an xcode cocoa app from launchd. I have tried loading 2 different versions of a plist that reference either the executable, or the .app bundle. Neither works. I noticed a prior listing explaining that the actual exe must be referenced, not the .app bundle. ps shows that the process actually gets created both ways. However, nothing appears. I am able to launch the app successfully from a script file and the cmd-line. But when the script file (which launches the app) is run via launchd, again nothing happens. I am using WatchPaths, and the Program key has been set to either the executable, or the .app bundle. Any suggestions out there? thanks...bob -- View this message in context: http://www.nabble.com/launch-cocoa-app-%28with-gui%29-from-launchd-tp14265985p14265985.html Sent from the Launchd mailing list archive at Nabble.com. From kvv at apple.com Tue Dec 11 12:52:52 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Tue Dec 11 12:53:35 2007 Subject: [launchd-dev] launch cocoa-app (with gui) from launchd In-Reply-To: <14265985.post@talk.nabble.com> References: <14265985.post@talk.nabble.com> Message-ID: Are you sure you're loading the job with the per-user launchd? Which directory is the launchd plist installed in? - Kevin On Dec 10, 2007, at 5:46 PM, bob kells wrote: > I have been unsuccessful so far attempting to launch an xcode cocoa > app > from launchd. I have tried loading 2 different versions of a plist > that > reference either > the executable, or the .app bundle. Neither works. I noticed a prior > listing explaining > that the actual exe must be referenced, not the .app bundle. ps > shows that > the process actually gets > created both ways. However, nothing appears. I am able to launch > the app > successfully from a > script file and the cmd-line. But when the script file (which > launches the > app) is run > via launchd, again nothing happens. I am using WatchPaths, and the > Program > key has been set > to either the executable, or the .app bundle. Any suggestions out > there? > thanks...bob From zarzycki at apple.com Tue Dec 11 13:07:18 2007 From: zarzycki at apple.com (Dave Zarzycki) Date: Tue Dec 11 13:08:44 2007 Subject: [launchd-dev] launch cocoa-app (with gui) from launchd In-Reply-To: References: <14265985.post@talk.nabble.com> Message-ID: And what command line arguments are you using? On Dec 11, 2007, at 12:52 PM, Kevin Van Vechten wrote: > Are you sure you're loading the job with the per-user launchd? > Which directory is the launchd plist installed in? > > - Kevin > > On Dec 10, 2007, at 5:46 PM, bob kells wrote: > >> I have been unsuccessful so far attempting to launch an xcode cocoa >> app >> from launchd. I have tried loading 2 different versions of a plist >> that >> reference either >> the executable, or the .app bundle. Neither works. I noticed a >> prior >> listing explaining >> that the actual exe must be referenced, not the .app bundle. ps >> shows that >> the process actually gets >> created both ways. However, nothing appears. I am able to launch >> the app >> successfully from a >> script file and the cmd-line. But when the script file (which >> launches the >> app) is run >> via launchd, again nothing happens. I am using WatchPaths, and the >> Program >> key has been set >> to either the executable, or the .app bundle. Any suggestions out >> there? >> thanks...bob > > _______________________________________________ > launchd-dev mailing list > launchd-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/launchd-dev From bobkells at steelcape.com Tue Dec 11 16:36:36 2007 From: bobkells at steelcape.com (Bob Kells) Date: Tue Dec 11 16:34:20 2007 Subject: [launchd-dev] launch cocoa-app (with gui) from launchd In-Reply-To: References: <14265985.post@talk.nabble.com> Message-ID: <3D084F05-E0EB-4EA9-AF16-8B1A3F966EF4@steelcape.com> So now I know where the problem is, but not the solution. First, my launchd plist is in ~/Library/LaunchAgents, and that is my location when I issue commands to launchctl. The OnDemand key/value is set to true. I am looking for files on a specific path via WatchPaths. I have 2 cmd-line args; "-d 4 -p /Users/bob/LaunchScriptTest". The launchd plist contains the Program key, and I have also set the first arg to the app-name. My cocoa app is used to generate custom NSAlert messages, and is currently being executed from a script file. Ideally, it will be executed by launchd directly. The alert panels appear correctly when I run the app from both the cmd-line and the script file. When the app is run from the same script file, when the script file is launched by launchd, it hangs at the call to the runModal method of my NSAlert object. I have tailed my system-log and watched a list of info messages from the app, and everything is ok. The cmd-line args sent to the app from launchd are correct. I have a custom object connected to the File's Owner in IB, and issue the call to runModal from the applicationDidFinishLaunching method. I know there are some things that launchd specifically says are prohibited, such as a fork/exit. Does runModal attempt any of these restrictions? This is an interesting problem. Thanks for getting back to me so quickly...bob On Dec 11, 2007, at 12:52 PM, Kevin Van Vechten wrote: > Are you sure you're loading the job with the per-user launchd? > Which directory is the launchd plist installed in? > > - Kevin > > On Dec 10, 2007, at 5:46 PM, bob kells wrote: > >> I have been unsuccessful so far attempting to launch an xcode >> cocoa app >> from launchd. I have tried loading 2 different versions of a >> plist that >> reference either >> the executable, or the .app bundle. Neither works. I noticed a >> prior >> listing explaining >> that the actual exe must be referenced, not the .app bundle. ps >> shows that >> the process actually gets >> created both ways. However, nothing appears. I am able to launch >> the app >> successfully from a >> script file and the cmd-line. But when the script file (which >> launches the >> app) is run >> via launchd, again nothing happens. I am using WatchPaths, and >> the Program >> key has been set >> to either the executable, or the .app bundle. Any suggestions out >> there? >> thanks...bob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071211/9500dfbd/attachment-0001.html From bobkells at steelcape.com Tue Dec 11 18:04:57 2007 From: bobkells at steelcape.com (Bob Kells) Date: Tue Dec 11 18:02:39 2007 Subject: [launchd-dev] launch cocoa-app (with gui) from launchd Message-ID: <50D9D1B4-5975-41BD-8B36-0C0CF7404919@steelcape.com> Problem may be resolved. I'm looking at my code that issues the runModal call. My NSAlert object is created within a loop that depends on the number of alerts to display. I was retain/releasing this object within the loop. I noticed that NSAlert is autoreleased, so I removed the retain/release statements, and now I get my alert panels. Again, this worked outside of launchd with the retain/release. But now it appears to be working when launched from launchd. My next step is to skip the script, and call it directly from launchd. I'll let you know the outcome tomorrow...bob From louis.granboulan at gmail.com Thu Dec 13 07:24:19 2007 From: louis.granboulan at gmail.com (Louis Granboulan) Date: Thu Dec 13 08:25:44 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: References: Message-ID: Le 5 d?c. 07 ? 16:04, Jeremy Reichman a ?crit : > I would be just as happy if there were a file that was consistently > and > reliably modified during network changes, so that the WatchPaths > key could > be used. I'm not aware of such a file and past discussions about > this on the > MacEnterprise list haven't turned one up (to my recollection), but > that > doesn't mean it doesn't exist. Maybe /private/var/run/resolv.conf (which is also /var/run/ resolv.conf and /etc/resolv.conf) By the way, has anyone a comprehensive reference on how name resolving is parameterized in MacOSX? For example, who changes the resolv.conf file, and who uses it? Louis From bobkells at steelcape.com Fri Dec 14 14:13:07 2007 From: bobkells at steelcape.com (bobkells@steelcape.com) Date: Fri Dec 14 14:12:37 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd Message-ID: <20300636.539531197670387528.JavaMail.nabble@isper.nabble.com> Not having any luck running a LaunchAgent containing a gui from launchd. Is this simply not possible? From subscriber at gloaming.com Fri Dec 14 15:30:02 2007 From: subscriber at gloaming.com (James Bucanek) Date: Fri Dec 14 15:29:35 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <20300636.539531197670387528.JavaMail.nabble@isper.nabble.com> Message-ID: bobkells@steelcape.com wrote (Friday, December 14, 2007 3:13 PM -0800): >Not having any luck running a LaunchAgent containing a gui from launchd. >Is this simply not possible? I'm running both GUI and non-GUI agents (~/Library/LaunchAgents) using launchd. Try telling us what your .plist contains and describe the problems your having. -- James Bucanek From bobkells at steelcape.com Fri Dec 14 16:51:20 2007 From: bobkells at steelcape.com (Bob Kells) Date: Fri Dec 14 16:48:59 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: References: Message-ID: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> Thanks for getting back to me. Here is some info about the plist. I had to cut the app gui-calls as the message was too big. It feels like I am missing something obvious...bob I have been running a cocoa-app with a simple gui two different ways. 1. Run from a script file at the cmd-line. This runs fine. I check various fields by tailing the system.log. The alert panels appear as I expect. 2. Run by the same script file, which is run by launchd. The app is recognized and starts up. I can see the same fields in the tailed system log. The app run ok until it hangs in the call to [oAlert runModal]; I also try to run the app directly from launchd. I get the same effect as in #2 above. Here is the launchd plist. It is located in ~/Library/LaunchAgents. I cd here to issue all the launchctl calls. I have tried various permutations, such as the full path in the Program-key value. Disabled Label net.aquaconnect.acnotify OnDemand Program ACNotify ProgramArguments /Users/bob/AppSupport/ACNotify.app/Contents/ MacOS/ACNotify -d 4 -p /Users/bob/LaunchScriptTest QueueDirectories /Users/bob/LaunchScriptTest ServiceDescription Aquaconnect Alert Notification Manager WorkingDirectory /Users/bob/AppSupport/ACNotify.app/Contents/MacOS On Dec 14, 2007, at 3:30 PM, James Bucanek wrote: > bobkells@steelcape.com wrote > (Friday, December 14, 2007 3:13 PM -0800): > >> Not having any luck running a LaunchAgent containing a gui from >> launchd. >> Is this simply not possible? > > I'm running both GUI and non-GUI agents (~/Library/LaunchAgents) > using launchd. > > Try telling us what your .plist contains and describe the problems > your having. > > -- > James Bucanek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071214/59dd02e4/attachment-0001.html From launchd at khiltd.com Fri Dec 14 17:00:02 2007 From: launchd at khiltd.com (Nathan Duran) Date: Fri Dec 14 16:59:33 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> Message-ID: <629C9FEE-66F7-48C6-BE82-01FB6C5ABB57@khiltd.com> On Dec 14, 2007, at 4:51 PM, Bob Kells wrote: > I had to cut the app gui-calls as the message was too big. Disable HTML in your mail client and watch those messages shrink. From hamish at gmail.com Fri Dec 14 17:11:52 2007 From: hamish at gmail.com (Hamish Allan) Date: Fri Dec 14 17:11:20 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> Message-ID: <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> On Dec 15, 2007 12:51 AM, Bob Kells wrote: > Here is the launchd plist. > It is located in ~/Library/LaunchAgents. > I cd here to issue all the launchctl calls. What arguments are you passing to launchctl? Hamish From bobkells at steelcape.com Fri Dec 14 17:18:42 2007 From: bobkells at steelcape.com (Bob Kells) Date: Fri Dec 14 17:16:19 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> Message-ID: launchctl load -w net.aquaconnect.acnotify.plist launchctl unload -w net.aquaconnect.acnotify.plist launchctl list Also, I have root priv when doing this. On Dec 14, 2007, at 5:11 PM, Hamish Allan wrote: > On Dec 15, 2007 12:51 AM, Bob Kells wrote: > >> Here is the launchd plist. >> It is located in ~/Library/LaunchAgents. >> I cd here to issue all the launchctl calls. > > What arguments are you passing to launchctl? > > Hamish > From hamish at gmail.com Fri Dec 14 17:18:49 2007 From: hamish at gmail.com (Hamish Allan) Date: Fri Dec 14 17:18:17 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> Message-ID: <597e7edb0712141718s429b178dl18ef64f1b31ea18a@mail.gmail.com> Try: $ launchctl load -S Aqua -w net.aquaconnect.acnotify.plist HTH, H On Dec 15, 2007 1:18 AM, Bob Kells wrote: > > launchctl load -w net.aquaconnect.acnotify.plist > launchctl unload -w net.aquaconnect.acnotify.plist > launchctl list > > Also, I have root priv when doing this. > > > On Dec 14, 2007, at 5:11 PM, Hamish Allan wrote: > > > On Dec 15, 2007 12:51 AM, Bob Kells wrote: > > > >> Here is the launchd plist. > >> It is located in ~/Library/LaunchAgents. > >> I cd here to issue all the launchctl calls. > > > > What arguments are you passing to launchctl? > > > > Hamish > > > > From bobkells at steelcape.com Fri Dec 14 17:26:16 2007 From: bobkells at steelcape.com (Bob Kells) Date: Fri Dec 14 17:23:53 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <597e7edb0712141718s429b178dl18ef64f1b31ea18a@mail.gmail.com> References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> <597e7edb0712141718s429b178dl18ef64f1b31ea18a@mail.gmail.com> Message-ID: That gives me an "illegal option" message. Am I running an old version? How can I tell? On Dec 14, 2007, at 5:18 PM, Hamish Allan wrote: > Try: > > $ launchctl load -S Aqua -w net.aquaconnect.acnotify.plist > > HTH, > H > > On Dec 15, 2007 1:18 AM, Bob Kells wrote: >> >> launchctl load -w net.aquaconnect.acnotify.plist >> launchctl unload -w net.aquaconnect.acnotify.plist >> launchctl list >> >> Also, I have root priv when doing this. >> >> >> On Dec 14, 2007, at 5:11 PM, Hamish Allan wrote: >> >>> On Dec 15, 2007 12:51 AM, Bob Kells wrote: >>> >>>> Here is the launchd plist. >>>> It is located in ~/Library/LaunchAgents. >>>> I cd here to issue all the launchctl calls. >>> >>> What arguments are you passing to launchctl? >>> >>> Hamish >>> >> >> > From hamish at gmail.com Fri Dec 14 17:27:09 2007 From: hamish at gmail.com (Hamish Allan) Date: Fri Dec 14 17:26:37 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> <597e7edb0712141718s429b178dl18ef64f1b31ea18a@mail.gmail.com> Message-ID: <597e7edb0712141727g3a1d2ffh7dc8bcdfbe9c566e@mail.gmail.com> Did you use a capital -S? Hamish On Dec 15, 2007 1:26 AM, Bob Kells wrote: > That gives me an "illegal option" message. > Am I running an old version? How can I tell? > > > On Dec 14, 2007, at 5:18 PM, Hamish Allan wrote: > > > Try: > > > > $ launchctl load -S Aqua -w net.aquaconnect.acnotify.plist > > > > HTH, > > H > > > > On Dec 15, 2007 1:18 AM, Bob Kells wrote: > >> > >> launchctl load -w net.aquaconnect.acnotify.plist > >> launchctl unload -w net.aquaconnect.acnotify.plist > >> launchctl list > >> > >> Also, I have root priv when doing this. > >> > >> > >> On Dec 14, 2007, at 5:11 PM, Hamish Allan wrote: > >> > >>> On Dec 15, 2007 12:51 AM, Bob Kells wrote: > >>> > >>>> Here is the launchd plist. > >>>> It is located in ~/Library/LaunchAgents. > >>>> I cd here to issue all the launchctl calls. > >>> > >>> What arguments are you passing to launchctl? > >>> > >>> Hamish > >>> > >> > >> > > > > From bobkells at steelcape.com Fri Dec 14 17:32:31 2007 From: bobkells at steelcape.com (Bob Kells) Date: Fri Dec 14 17:30:09 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: <597e7edb0712141727g3a1d2ffh7dc8bcdfbe9c566e@mail.gmail.com> References: <088C0914-ACE3-461D-8D64-5D800D5B4D2F@steelcape.com> <597e7edb0712141711l182c1f27l1d5d0715a832b0be@mail.gmail.com> <597e7edb0712141718s429b178dl18ef64f1b31ea18a@mail.gmail.com> <597e7edb0712141727g3a1d2ffh7dc8bcdfbe9c566e@mail.gmail.com> Message-ID: <92692927-2C2C-496F-B4A8-97D7B5298A7B@steelcape.com> Both upper and lowercase. On Dec 14, 2007, at 5:27 PM, Hamish Allan wrote: > Did you use a capital -S? > > Hamish > > On Dec 15, 2007 1:26 AM, Bob Kells wrote: >> That gives me an "illegal option" message. >> Am I running an old version? How can I tell? >> >> >> On Dec 14, 2007, at 5:18 PM, Hamish Allan wrote: >> >>> Try: >>> >>> $ launchctl load -S Aqua -w net.aquaconnect.acnotify.plist >>> >>> HTH, >>> H >>> >>> On Dec 15, 2007 1:18 AM, Bob Kells wrote: >>>> >>>> launchctl load -w net.aquaconnect.acnotify.plist >>>> launchctl unload -w net.aquaconnect.acnotify.plist >>>> launchctl list >>>> >>>> Also, I have root priv when doing this. >>>> >>>> >>>> On Dec 14, 2007, at 5:11 PM, Hamish Allan wrote: >>>> >>>>> On Dec 15, 2007 12:51 AM, Bob Kells >>>>> wrote: >>>>> >>>>>> Here is the launchd plist. >>>>>> It is located in ~/Library/LaunchAgents. >>>>>> I cd here to issue all the launchctl calls. >>>>> >>>>> What arguments are you passing to launchctl? >>>>> >>>>> Hamish >>>>> >>>> >>>> >>> >> >> > From huntc at internode.on.net Fri Dec 14 17:43:32 2007 From: huntc at internode.on.net (Christopher Hunt) Date: Fri Dec 14 17:43:04 2007 Subject: [launchd-dev] Run job when network configuration changes In-Reply-To: <20071215004901.5E4ED16B794@lists.macosforge.org> References: <20071215004901.5E4ED16B794@lists.macosforge.org> Message-ID: Le 5 d?c. 07 ? 16:04, Jeremy Reichman a ?crit : > I would be just as happy if there were a file that was > consistently and > reliably modified during network changes, so that the WatchPaths > key could > be used. I'm not aware of such a file and past discussions about > this on the > MacEnterprise list haven't turned one up (to my recollection), but > that > doesn't mean it doesn't exist. > I've not really been following this thread but, if I were wanting to do this, I think I'd write a little bit of Cocoa to detect network configuration changes and write a file to a location that a launchd job watches. I following a similar strategy for some other launchd based actions. Works nicely. Cheers, -C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071215/07995d61/attachment-0001.html From bobkells at steelcape.com Fri Dec 14 16:44:11 2007 From: bobkells at steelcape.com (Bob Kells) Date: Fri Dec 14 17:57:18 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: References: Message-ID: Thanks for getting back to me. Here is some info about the plist and the app. It feels like I am missing something obvious...bob I have been running a cocoa-app with a simple gui two different ways. 1. Run from a script file at the cmd-line. This runs fine. I check various fields by tailing the system.log. The alert panels appear as I expect. 2. Run by the same script file, which is run by launchd. The app is recognized and starts up. I can see the same fields in the tailed system log. The app run ok until it hangs in the call to [oAlert runModal]; I also try to run the app directly from launchd. I get the same effect as in #2 above. Here is the launchd plist. It is located in ~/Library/LaunchAgents. I cd here to issue all the launchctl calls. I have tried various permutations, such as the full path in the Program-key value. Disabled Label net.aquaconnect.acnotify OnDemand Program ACNotify ProgramArguments /Users/bob/AppSupport/ACNotify.app/Contents/ MacOS/ACNotify -d 4 -p /Users/bob/LaunchScriptTest QueueDirectories /Users/bob/LaunchScriptTest ServiceDescription Aquaconnect Alert Notification Manager WorkingDirectory /Users/bob/AppSupport/ACNotify.app/Contents/MacOS Here are code snippets of the app being called. This lists all of the gui-related calls in the app. I have a custom object instantiated in IB, and connected to File's Owner for some delegate methods. Again, I have tried various permutation... Creating NSAlert via the init/alloc; removed the NSPanel calls. Have added LSUIElement-key with a value of 1 to the Info.plist of the xcode project. I did have retain/releases with the NSAlert, but removed them as the doc says it is autoreleased. // ------------------------------------------------------------------------ ---- int main(int argc, char *argv[]) { return NSApplicationMain(argc, (const char **) argv); } // ------------------------------------------------------------------------ ---- - (void) applicationDidFinishLaunching: (NSNotification *) aNotification // set focus to NSApp (forces its windows on top of all other windows) [NSApp activateIgnoringOtherApps: YES]; // ---------------------------------------------------------------- // create NSAlert object oAlert = [NSAlert alertWithMessageText: msgTitle defaultButton: b1Title alternateButton: nil otherButton: nil informativeTextWithFormat: msgInfo]; [oAlert setAlertStyle: NSWarningAlertStyle]; oPanel = [oAlert window]; [oPanel orderFront: self]; *****HERE IS WHERE THE CODE HANGS***** iButton = [oAlert runModal]; [NSApp terminate: self]; // ------------------------------------------------------------------------ ---- - (NSApplicationTerminateReply) applicationShouldTerminate: (NSApplication *) mApp return (NSTerminateNow); // ------------------------------------------------------------------------ ---- - (void) applicationWillTerminate: (NSNotification *) aNotification application cleanup On Dec 14, 2007, at 3:30 PM, James Bucanek wrote: > bobkells@steelcape.com wrote > (Friday, December 14, 2007 3:13 PM -0800): > >> Not having any luck running a LaunchAgent containing a gui from >> launchd. >> Is this simply not possible? > > I'm running both GUI and non-GUI agents (~/Library/LaunchAgents) > using launchd. > > Try telling us what your .plist contains and describe the problems > your having. > > -- > James Bucanek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/launchd-dev/attachments/20071214/89b9055e/attachment-0001.html From subscriber at gloaming.com Sat Dec 15 21:37:44 2007 From: subscriber at gloaming.com (James Bucanek) Date: Sat Dec 15 21:37:11 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: Message-ID: Bob Kells wrote (Friday, December 14, 2007 5:44 PM -0800): > > > > >Disabled > >Label >net.aquaconnect.acnotify >OnDemand > >Program >ACNotify >ProgramArguments > >/Users/bob/AppSupport/ACNotify.app/Contents/MacOS/ACNotify >-d >4 >-p >/Users/bob/LaunchScriptTest > >QueueDirectories > >/Users/bob/LaunchScriptTest > >ServiceDescription >Aquaconnect Alert Notification Manager >WorkingDirectory >/Users/bob/AppSupport/ACNotify.app/Contents/MacOS > > While there doesn't seem to be anything "wrong" with this plist, I've found that simpler is better when trying to debug these things. Since your first argument is already the complete path to the application binary, I'd eliminate both the Program and WorkingDirectory keys, since they're redundant. Bob Kells wrote (Friday, December 14, 2007 6:18 PM -0800): >launchctl load -w net.aquaconnect.acnotify.plist >launchctl unload -w net.aquaconnect.acnotify.plist >launchctl list > >Also, I have root priv when doing this. You should be issuing user-agent requests as the user, not root. You want the application to be loaded/executed for ~ not root. Bob Kells wrote (Friday, December 14, 2007 6:26 PM -0800): >That gives me an "illegal option" message. >Am I running an old version? How can I tell? The -S option was added is Leopard. -- James Bucanek From subscriber at gloaming.com Sat Dec 15 22:01:20 2007 From: subscriber at gloaming.com (James Bucanek) Date: Sat Dec 15 22:00:47 2007 Subject: [launchd-dev] run gui LaunchAgent from launchd In-Reply-To: Message-ID: James Bucanek wrote (Saturday, December 15, 2007 10:37 PM -0700): >Bob Kells wrote (Friday, December 14, 2007 6:26 PM -0800): > >>That gives me an "illegal option" message. >>Am I running an old version? How can I tell? > >The -S option was added is Leopard. Footnote: For GUI applications, LaunchAgents are essentially broken in Tiger. This will only work in Leopard. If you're trying to do this in Tiger, you'll need to use Login Items. -- James Bucanek From launchd at khiltd.com Sun Dec 16 19:00:26 2007 From: launchd at khiltd.com (Nathan Duran) Date: Sun Dec 16 18:59:48 2007 Subject: [launchd-dev] UserName ignored on per-user LaunchAgents In-Reply-To: References: <862F5C95-229B-4401-8E22-6AC32A93B248@apple.com> <6229CE91-1A63-4784-B1B7-606820D34D84@khiltd.com> Message-ID: <64FE14C6-7337-49F0-B61B-19ACA6138D02@khiltd.com> On Dec 5, 2007, at 9:51 AM, Quinn wrote: > At 9:31 -0800 5/12/07, Nathan Duran wrote: >> I'm afraid I don't understand what is meant by the term "external >> form" here. Are you suggesting that the authorization API be used >> to prevent rogue applications from utilizing the IPC services >> vended by the daemon? > > For a concrete illustration of this, check out the recently released > BetterAuthorizationSample. > > > > > Share and Enjoy I finally had a chance to sit down and look over this, and while I think it may be a great approach for an application which needs to perform certain tasks as root on an ongoing basis, I don't think it's a privileged operations panacea, however secure it may be. In particular, it strikes me as overkill to litter /Library and /var with support files and dance around with complicated launchd IPC maneuvers at times when all I need to do is create a keychain item or install a trusted root certificate as part of a larger software installation. Things like this are usually run once before they're thrown away, and since something's going to have to ask for permission to write all those root-owned plists out anyway, might as well get it over with right then and there the old fashioned AEWP/setuid way. Cool stuff, but I unfortunately can't replace any of the helper tools I've got with it. The asl_log() thing sounds interesting, though. What list should I complain about the lack of documentation/evangelization for that on? I didn't even know it existed.