- launchd-dev - lists.macosforge.org

Re: [launchd-dev] Binding an individual user's agent to a privileged port
by Hamish Allan 28 Jan '08

28 Jan '08

On Jan 28, 2008 11:30 AM, Quinn <eskimo1(a)apple.com> wrote: > launchd agents are managed by the per-user launchds. Those launchds > have irrevocably dropped all privileges. Thus, there's no way for > them to be able to bind to a privileged port on your behalf. Good news for security. Bad news for my purposes! On Jan 28, 2008 11:30 AM, Quinn <eskimo1(a)apple.com> wrote: > At 22:23 +0000 23/1/08, Hamish Allan wrote: >>As far as I can tell, there are two ways of demonstrating to launchd >>that you have the authority to perform privileged operations such as >>binding to a port < 1024: putting a plist file in /Library/Launch*, or >>running launchctl sudo. > > I believe you mean "/Library/LaunchDaemons" and not > "/Library/Launch*". The latter would include agents (in > "/Library/LaunchAgents"), which are restricted as I've described > above. FWIW, I *did* mean /Library/Launch*: putting a file in /Library/LaunchAgents does demonstrate that you have the *authority* to perform privileged operations (because its permissions are the same as those of /Library/LaunchDaemons), but the architecture of launchd prevents this from being translated into actual privileges. On Jan 28, 2008 11:30 AM, Quinn <eskimo1(a)apple.com> wrote: > btw These two mechanism are fundamentally the same. > > o When you put a file in "/Library/LaunchDaemons", it is consulted by > the root launchd at system startup. > > o When you run launchctl using sudo, it always talks to the root launchd. > > Thus, in both cases the launchd job gets loaded into the root > launchd, which is the only one capable of binding to privileged ports. Aha. Makes sense. Good to know. Thanks, Hamish

1 0

Binding an individual user's agent to a privileged port
by Hamish Allan 28 Jan '08

28 Jan '08

>From "Getting started with launchd" (http://developer.apple.com/macosx/launchd.html) "Of particular interest is that launchd can run a job as a non-root user, but still bind it to a privileged port. This removes one common reason to run daemons as root." Is it possible for a user agent to be bound to a privileged port? This might sound like an odd thing to do, but I wish to automatically mount a remote SMB share on my local machine using SSH port forwarding. Unfortunately, since Finder is too stupid to let me mount shares at alternative ports on localhost (it tells me that I should just access the files locally!) and mount_smbfs doesn't take a port argument, I need to bind the remote ports 139 and 445 to the same ports on my local machine. I want this as an agent rather than a daemon for the purposes of SSH key management. It needs to run as an agent in the GUI context when I log in, as this is where the automatic SSH_AUTH_SOCK facility in Leopard lives. As far as I can tell, there are two ways of demonstrating to launchd that you have the authority to perform privileged operations such as binding to a port < 1024: putting a plist file in /Library/Launch*, or running launchctl sudo. The former means that the operation would be executed for all users, and the latter is sort of missing the point of the original exercise (not to mention bringing file permissions problems of its own). Is what I am trying to do possible with launchd? Hamish

2 1

launchd not loading for me in Leopard
by Eddy Martinez 19 Jan '08

19 Jan '08

Hello, I've been searching around and have not been able to find any hints. I have a plist, pref pane based app that fires off at a preset time. With Tiger its all good. However Leopard is failing to run the app at the scheduled time. Pasted are some errors that I hope will help to identify the problem. I'm not the developer, who is a contractor dealing with another deadline. I'm hoping to gather information on his behalf in order to expedite the resolution. I have access to the dev boxes and can run commands and capture any needed output. Any help appreciated, and thanks in advance, Eddy vmini01:~ $ cat /tmp/agentLauncher.stderr 2008-01-17 12:38:00.136 AgentLauncher[218:20b] Cannot checkin with launchd, exiting. 2008-01-17 14:14:00.032 AgentLauncher[323:20b] Cannot checkin with launchd, exiting. 2008-01-17 14:36:00.057 AgentLauncher[389:20b] Cannot checkin with launchd, exiting. vmini01:~ $ vmini01:~$ tail -f /var/log/system.log | grep devapp Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for array: excluded Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for boolean: Enabled Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for array: included Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key: ServiceDescription Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key: server Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for string: cistern Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key: bucket Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for integer: finish Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key for string: CustomerID Jan 18 10:54:44 vmini01 com.apple.launchd[1] (com.devapp.AgentLauncher): Unknown key: CustomerID vmini01:~ eddy$ sudo launchctl list | grep devapp - 1 com.devapp.AgentLauncher vmini01:~ $ ls -la /Library/LaunchDaemons/ total 8 drwxr-xr-x 3 root wheel 102 Jan 18 10:54 . drwxrwxr-t+ 46 root admin 1564 Sep 14 10:14 .. -rw-r--r-- 1 root wheel 1248 Jan 18 10:54 com.devapp.AgentLauncher.plist vmini01:~ $ -- Eddy Martinez fasteddy760(a)gmail.com

3 5

Loading LaunchDaemons
by Jeremy Reichman 18 Jan '08

18 Jan '08

Do new jobs that are copied to a directory like /Library/LaunchDaemons get loaded automatically by the system at startup, so that they run when they would normally be scheduled? Or must we specifically load them with launchctl? I've looked back through the launchd and launchctl man pages and I don't see there whether a new job must be explicitly loaded, or if simply having it in the right directory at startup is enough to load/activate it. I have a custom LaunchDaemon which works fine when loaded -- I'm very enthusiastic about how well it works on Leopard vs. Tiger, because the job is scheduled to run when systems are typically asleep. The new behavior of running the job at wakeup is great. Anyway, on some systems (all of which are Intel-based Macs running 10.5.1 with all current updates except for iTunes 7.6 and QuickTime 7.4), the job I've installed does not and has not been running, even though the computers in question have been rebooted multiple times. It appears the job itself is not loading; when I grep for it in the long results of `launchctl list`, I don't see it. (Loading it manually does show that it is loaded, of course.) The LaunchDaemon file was installed by a simple copy -- actually, via the Radmind system management tool. Ergo, `launchctl load` was never explicitly run on it on any of the systems, but I seem to get different behavior -- some load it, some don't. (I'm still in the process of collecting information on where it works and where it doesn't.) Thanks! -- Jeremy

3 4

launchd support ranges for StartCalendarInterval?
by Richard Glaser 17 Jan '08

17 Jan '08

FYI: Sorry, for this slightly off-topic.. Does launchd does support ranges say for "Days" in the StartCalendarInterval? For example, with cron if I wanted to run a script on the first & third Sunday of each month at 4 AM. I could use this code with a range... # minute hour mday month wday who command 0 4 1-7,15-21 * 0 root /path/to/script1 Then I could run another script the second & fourth Sunday of each month at 4 AM... # minute hour mday month wday who command 0 4 8-14,22-31 * 0 root /path/to/script2 Is this possible with launchd? Thanks: Richard Glaser University of Utah - Student Computing Labs richard(a)scl.utah.edu 801-585-8016

2 2

A launchd blog post
by Dave Zarzycki 16 Jan '08

16 Jan '08

And while we are on the topic of the last email, I just created a blog post: http://launchd.macosforge.org/?p=5 Cheers, davez

1 0

launchd misinterpreting cron ranges?
by Richard Glaser 16 Jan '08

16 Jan '08

FYI: Sorry, for this slightly off-topic.. I used the following cron lines with Mac OS X 10.4.11 Server, but with Mac OS X 10.5.1 Server it doesn't run correctly. It runs the scripts every day, versus 1st & 3rd or 2nd or 4th Sunday at 4 AM. # minute hour mday month wday who command 0 4 1-7,15-21 * 0 root /path/to/script1 0 4 8-14,22-31 * 0 root /path/to/script2 Is this a bug or is there a workaround? Thanks: Richard Glaser University of Utah - Student Computing Labs richard(a)scl.utah.edu 801-585-8016

1 0

launchd for windows
by Pavel Repin 03 Jan '08

03 Jan '08

Hi, Has anyone heard of or personally done any work on porting launchd to Windows? I know Vista has WAS (which is sort of like launchd but mostly tailored for deamon-like services), but launchd, if ported, has no reason to be exclusively tied to Vista, it can work on any version of Windows still in use. On one occassion, I've implemented an enormously severe subset of launchd which can be summarized by the only type of process configuration plist supported: <plist version="1.0"> <dict> <key>Label</key> <string>my.service.1</string> <key>ProgramArguments</key> <array> <string>myservice1.exe</string> <string>-k run</string> </array> <key>OnDemand</key> <false /> </dict> </plist> And it was fun to do. I wonder if someone was more productive. -- Pavel Repin

1 0

UserName ignored on per-user LaunchAgents
by Jeremy Reichman 17 Dec '07

17 Dec '07

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 <string> 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

6 12

run gui LaunchAgent from launchd
by bobkells＠steelcape.com 16 Dec '07

16 Dec '07

Not having any luck running a LaunchAgent containing a gui from launchd. Is this simply not possible?

5 12