Re: launchd and programmatic access
Re: launchd and programmatic access
- Subject: Re: launchd and programmatic access
- From: Jason Coco <email@hidden>
- Date: Fri, 3 Oct 2008 17:04:40 -0400
On Oct 3, 2008, at 16:48 , Damien Sorresso wrote:
On Oct 3, 2008, at 1:36 PM, Jason Coco wrote:
On Oct 3, 2008, at 16:26 , Damien Sorresso wrote:
On Oct 3, 2008, at 1:05 PM, Jordan K. Hubbard wrote:
On Oct 3, 2008, at 8:02 PM, Damien Sorresso wrote:
The pref pane includes a setuid helper application that does
proper authorization, etc.
Your privileged operations should be done in your daemon. We
heavily discourage the use of setuid tools, and we're actively
trying to cleanse the system of them.
Just so I understand what you're advocating here... Are you
seriously suggesting that the entire daemon should be privileged
rather than using a privilege-separated helper tool? That seems
to run counter to generally accepted security practices (make
privileged things as small as possible), so I must be mis-parsing
your recommendations here...
He mentioned that his daemon's plist lives in /Library/
LaunchDaemons and that it was a privileged operation to talk to
it, and I mistakenly interpreted that as "My daemon is running as
root", which is not necessarily true.
So no, I'm not advocating that all system-wide daemons run as
root; I mistakenly concluded that his was.
Actually, it is because it needs to bind to a privileged port.
I have another question, tho, Damien. If I want to use a UNIX
socket to do the IPC, do I have to create the socket myself?
launchd doesn't seem to create and
bind it when I use the SockPathName key...
launchctl will create the socket for you when you load your job. It
will give a file descriptor for that socket to launchd, and launchd
will give that descriptor to your job when you check in via the
launch(3) API.
How are you specifying your socket in your launchd.plist(5)?
I was creating it with the SocketNamePath key in a dictionary I called
IPC in the Sockets dictionary... I realized my problem though, I was
using an intermediate directory that didn't exist and I guess
launchctl didn't want to create for me :) I changed it to use a full
path that already exists and it works just fine now. Thanks!!
Did you get a chance to read my other question about the design? I was
wondering if you had any opinion one way or the other... two launchd
entries with the java one dependent on the wrapper or having the
wrapper fork/exec the java process and then manage it actively.
J
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden