April 2009 - Darwin-dev - lists.apple.com

Re: Run daemon from installer as root
by Iceberg-Dev 05 Apr '09

05 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=sEJZa2BVNGDIMKJT0Hv2MxtYcJxfQBIQwgB3lCP81uE=; b=ZdnULvn5MZvceUgY4ehB50ySNq2OonMRDbG4b9S9F77cwnArg+V9MnhPtxBmbETDrR wX3ORV9eHYcLDz7Er2YQwuSA6QoZH32Y2bTXOVcuNOweyxEP/JCp3k7I+JpGuFMF826i 9yUY9BvQwnumDs2WADUjwkkQUcPNfkPS/ejXQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=thDf843iM/kzznQOJoV/d8u1tFAoiAaryKonCOqZPjmL7FzxfiGft8aj18Kr//NDPa RZE5bSEDpGENPpBBtR3Dtdu65SWO7COYT+84cxvPCYUdDLUmtJp06MPFCpoLGHCGcHmY /WdtzPd9zcepTtY+k/01MWZLmHMgX5rb2kQp8= On Apr 5, 2009, at 5:27 PM, Duane Murphy wrote: --- At Sun, 5 Apr 2009 20:03:42 +0530, Rakesh Singhal wrote: Hi all, This is not a limitation of the installer. This is a limitation of the sh (and perl). Well, not really a limitation, it's a security feature. Some script interpreters will refuse to run a script as root as a security precaution. I don't recall the exact details about when this choice is made or how to overcome it. My choice for overcoming the problem was to choose a different interpreter (python). I suppose it's just a matter of time before that door is closed also. I'd like to know what the alternatives are so that scripts within an installer can be run with Administrator/root privileges. Just in case, a simple solution is probably to: 1) Be sure that the installer requires an admon/root authentication. 2) Use sudo to call launchctl even from the shell script. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I have created an installer for my daemon application. I want my daemon to run as root after installation. Before installation I used to run daemon using "sudo launchctl load /Library/LaunchDaemons/ com.mycompany.mydaemon.plist". In installer I tried using run command or run script but it works only in 10.4.11 ppc but not with 10.5.4 intel. I want to set some file permissions/ownerships also but it doesnt work. Installer can be run only from admin users. Is there anyway to run daemon as root using command or script? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Run daemon from installer as root
by Duane Murphy 05 Apr '09

05 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com --- At Sun, 5 Apr 2009 20:03:42 +0530, Rakesh Singhal wrote: >Hi all, > >I have created an installer for my daemon application. I want my daemon >to run as root after installation. Before installation I used to run >daemon using "sudo launchctl load /Library/LaunchDaemons/ >com.mycompany.mydaemon.plist". In installer I tried using run command or >run script but it works only in 10.4.11 ppc but not with 10.5.4 intel. I >want to set some file permissions/ownerships also but it doesnt work. >Installer can be run only from admin users. Is there anyway to run >daemon as root using command or script? This is not a limitation of the installer. This is a limitation of the sh (and perl). Well, not really a limitation, it's a security feature. Some script interpreters will refuse to run a script as root as a security precaution. I don't recall the exact details about when this choice is made or how to overcome it. My choice for overcoming the problem was to choose a different interpreter (python). I suppose it's just a matter of time before that door is closed also. I'd like to know what the alternatives are so that scripts within an installer can be run with Administrator/root privileges. ...Duane _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Run daemon from installer as root
by Rakesh Singhal 05 Apr '09

05 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pTJOafSk/JhTlczKI9MN6hlWYuRdsLEuJYV/gVQMXTk=; b=A6I3BqmTsH2huyYnQxB+XHsPf8lIl6X+s38KLlwldMNJU1qhwvcBeFqANRCHXTkMb5 uY/BMYUHGmNwNIsC5yv2dB1rXI66xntMioD8g35mtOQ3FDIt78YCh/Ch58roJoo74MBB XA3kJAkowlyU4d5U/SVQmk8PsAxaRJKEETnJU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=L7KXCbFB0yh/lV0atJct2wJpxRIbLEkdBS2giKD1VHw8lP875mkXQ2G5b1PVslUxRV 5M/eOs+kzW2SHLwT60hZJGO1ZSTD0sOYGfeM38sb/HKP11nfTz1E5Ypg8CY7LNWbf8x8 WXHv04elCtzwb1tXSxduQ+hfMBbQR8hcKgtZ8= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

bootstraping a server in a running process without bootstrap_create_server
by Vincent Beliveau 04 Apr '09

04 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=h48xRG5hSlGTIYtaYZpRUtcEYiI74sIAcjkA11Kxa08=; b=ez1hZ+YdJ+zPlMdPenXu1zukeOPJRMWeguiAVVfxxNZyjVa0Jj8hAC1GB54obOZ6aR RCuuBwoK60bH8JpUg8CrtGnDhnVvjEy4xg9fOvCd7Pu/nxZdlkM2eti07IIdhZ1Z1ri2 DCJn0lmL1my2VWQSCyjMb5ztpDYhdb9wucIoo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EbViGr3F/UldyQbuUQrn4CDGZwEHf/H3fnYJz+cS/tZcOpGKHK4vVh8XJtdbxxiXTa x+BKFXXKS7OYyI5uxV6VCqsozbeygK3U6hM4h4Cl764pwp5KvrNfUVbVqxPnkA2Yxe9I 4R30cVkcDaWk7JELAOq0qIqqEkbbIwU3Jpx0s= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: should setsid() create new bootstrap context?
by Damien Sorresso 04 Apr '09

04 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I think the root of my recent trouble with Darwin daemons is that I expected a call to setsid() to create a new bootstrap context. However, it doesn't seem to do that. Is that a bug in Darwin? As it is, when I call fork() ==> process B setsid() ==> process group B fork() ==> process C exec() as a non-root user from a bootstrap context which is then terminated (say, an SSH login), I wind up with process C having a bad bootstrap context. There are two possible reasons for this that I can see: or 2. setsid() does create a new BC, but process B is the group leader, and the termination of B destroys the new context, so C winds up with an invalid BC. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com On Apr 3, 2009, at 3:36 PM, Terry Lambert wrote: On Apr 3, 2009, at 12:42 PM, Bill Janssen wrote: Damien Sorresso <dsorresso(a)apple.com> wrote: On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: Why would you expect this? Well, perhaps I'm just confused about the mapping of POSIX "session" onto Darwin. I thought the whole point of setsid() is to create a new process group that was independent of the pre-setsid process group. I'd expect it to create a new bootstrap context that would also be independent of the bootstrap context existing before setsid() was called, so that that the process group in that parent session could be terminated without affecting processes in the child session. 1. setsid() doesn't create a new bootstrap context for process group B, I'd appreciate more insight into this... POSIX sessions and launchd bootstrap sessions and Kerberos sessions and windowServer sessions and loginWindow sessions and securityd sessions and Common Criteria Auditing sessions, ..., are all orthogonal things. Expanding on this, we at Apple are just as aware of and frustrated with the utter confusion that these different notions of "sessions" generate as our external developers are. You're not alone. :) So, as a public service announcement, in the currently shipping Mac OS X (Leopard), the existing notions of sessions are as follows. • launchd bootstrap. This session type exists in a hierarchical structure. The system (i.e. PID 1) launchd provides the root bootstrap. Per-user launchd's provide sub-bootstraps for each user. Within each per-user bootstrap can be several sub-bootstraps for different entry points into the system (i.e. an "Aqua" bootstrap for graphical logins and a "StandardIO" bootstrap for SSH logins). Some processes may also call bootstrap_subset() to create sub-bootstraps for their own purposes. • WindowServer session. Very closely tied to a launchd bootstrap. WindowServer sessions are expressed by the presence of the "com.apple.WindowServer.session" MachService in a launchd bootstrap. When a client sends a message to that service port, WindowServer knows which port in its portset the message came from and assigns a session based on that. • securityd session. Very closely tied to a launchd bootstrap. securityd sessions are expressed by the presence of the "com.apple.SecurityServer" MachService in a launchd bootstrap. When a client sends a message to that service port, securityd knows which port in its portset the message came from and assigns a session based on that. • loginwindow session. This could also be described as a "graphical console session". loginwindow does a funny dance. It begins its life as a daemon in the system bootstrap, but when a user logs in, it packs up and moves itself (and its family) to the new user bootstrap that is created. So when loginwindow shows its UI, it's part of a "LoginWindow" bootstrap. After a user logs in, it becomes part of that new (per-user) bootstrap. If there are multiple users logged in at the console (i.e. through fast user-switching), there will be one loginwindow instance per console session to manage it. So if there are no users logged in, there is one loginwindow instance. If N users are logged in, there are N loginwindow instances. There are also Common Criteria auditing sessions, but those are only applicable on systems which have auditing turned on. Hope this helps. And again, sorry for all the confusion. We really do want to change it. -- Damien Sorresso BSD Engineering Apple Inc. smime.p7s

1 0

Re: should setsid() create new bootstrap context?
by Bill Janssen 04 Apr '09

04 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Terry Lambert <tlambert(a)apple.com> wrote: > On Apr 3, 2009, at 12:42 PM, Bill Janssen wrote: > > Damien Sorresso <dsorresso(a)apple.com> wrote: > >> On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: > >>> I think the root of my recent trouble with Darwin daemons is that I > >>> expected a call to setsid() to create a new bootstrap context. > >>> However, > >>> it doesn't seem to do that. Is that a bug in Darwin? > >> > >> Why would you expect this? > > > > Well, perhaps I'm just confused about the mapping of POSIX "session" > > onto Darwin. I thought the whole point of setsid() is to create a new > > process group that was independent of the pre-setsid process group. > > I'd > > expect it to create a new bootstrap context that would also be > > independent of the bootstrap context existing before setsid() was > > called, so that that the process group in that parent session could be > > terminated without affecting processes in the child session. > > > > As it is, when I call > > > > fork() ==> process B > > setsid() ==> process group B > > fork() ==> process C > > exec() > > > > as a non-root user from a bootstrap context which is then terminated > > (say, an SSH login), I wind up with process C having a bad bootstrap > > context. There are two possible reasons for this that I can see: > > > > 1. setsid() doesn't create a new bootstrap context for process > > group B, > > > > or > > > > 2. setsid() does create a new BC, but process B is the group leader, > > and the termination of B destroys the new context, so C winds up > > with an invalid BC. > > > > I'd appreciate more insight into this... > > POSIX sessions and launchd bootstrap sessions and Kerberos sessions > and windowServer sessions and loginWindow sessions and securityd > sessions and Common Criteria Auditing sessions, ..., are all > orthogonal things. > > Except for POSIX sessions, they are almost all either mostly or > entirely user-space constructs in the imagination of various daemons, > so it's not really reasonable to expect that a POSIX system call > interface would do anything to anything but the POSIX session. > > It's unfortunate that they are all confusingly named "* session" for > historical reasons, and it's unfortunate they they weren't treated as > nested containers from the start, but a lot of these things were > developed independently over time, and replacing the word "session" > with the word "container" wouldn't be any more helpful. > > Without requiring a directed acyclic hierarchical relationship between > them, however, this situation just isn't going to get resolved; _with_ > requiring it, you'd basically outlaw some existing, deployed use > models, which would be a bummer if you were one of the people who > depended on one of them, and it was suddenly yanked out from under > you. > > -- Terry Well, yes, but we coped with Apple's re-write of X11, too :-). Thanks, Terry. Perhaps I can finesse this by re-writing my daemon so that launchd can launch it. Then, if I set the "UserName" key to the right user, and the "KeepAlive" and "RunAtLoad" properties to "true", it should run in the startup bootstrap context, and restart automatically if the user kills it. Which should be close enough. Bill _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: should setsid() create new bootstrap context?
by Terry Lambert 03 Apr '09

03 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I think the root of my recent trouble with Darwin daemons is that I expected a call to setsid() to create a new bootstrap context. However, it doesn't seem to do that. Is that a bug in Darwin? As it is, when I call fork() ==> process B setsid() ==> process group B fork() ==> process C exec() as a non-root user from a bootstrap context which is then terminated (say, an SSH login), I wind up with process C having a bad bootstrap context. There are two possible reasons for this that I can see: or 2. setsid() does create a new BC, but process B is the group leader, and the termination of B destroys the new context, so C winds up with an invalid BC. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Apr 3, 2009, at 12:42 PM, Bill Janssen wrote: Damien Sorresso <dsorresso(a)apple.com> wrote: On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: Why would you expect this? Well, perhaps I'm just confused about the mapping of POSIX "session" onto Darwin. I thought the whole point of setsid() is to create a new process group that was independent of the pre-setsid process group. I'd expect it to create a new bootstrap context that would also be independent of the bootstrap context existing before setsid() was called, so that that the process group in that parent session could be terminated without affecting processes in the child session. 1. setsid() doesn't create a new bootstrap context for process group B, I'd appreciate more insight into this... POSIX sessions and launchd bootstrap sessions and Kerberos sessions and windowServer sessions and loginWindow sessions and securityd sessions and Common Criteria Auditing sessions, ..., are all orthogonal things. Except for POSIX sessions, they are almost all either mostly or entirely user-space constructs in the imagination of various daemons, so it's not really reasonable to expect that a POSIX system call interface would do anything to anything but the POSIX session. It's unfortunate that they are all confusingly named "* session" for historical reasons, and it's unfortunate they they weren't treated as nested containers from the start, but a lot of these things were developed independently over time, and replacing the word "session" with the word "container" wouldn't be any more helpful. Without requiring a directed acyclic hierarchical relationship between them, however, this situation just isn't going to get resolved; _with_ requiring it, you'd basically outlaw some existing, deployed use models, which would be a bummer if you were one of the people who depended on one of them, and it was suddenly yanked out from under you. This email sent to site_archiver(a)lists.apple.com

1 0

Re: should setsid() create new bootstrap context?
by Bill Janssen 03 Apr '09

03 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Damien Sorresso <dsorresso(a)apple.com> wrote: > On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: > > I think the root of my recent trouble with Darwin daemons is that I > > expected a call to setsid() to create a new bootstrap context. > > However, > > it doesn't seem to do that. Is that a bug in Darwin? > > Why would you expect this? Well, perhaps I'm just confused about the mapping of POSIX "session" onto Darwin. I thought the whole point of setsid() is to create a new process group that was independent of the pre-setsid process group. I'd expect it to create a new bootstrap context that would also be independent of the bootstrap context existing before setsid() was called, so that that the process group in that parent session could be terminated without affecting processes in the child session. As it is, when I call fork() ==> process B setsid() ==> process group B fork() ==> process C exec() as a non-root user from a bootstrap context which is then terminated (say, an SSH login), I wind up with process C having a bad bootstrap context. There are two possible reasons for this that I can see: 1. setsid() doesn't create a new bootstrap context for process group B, or 2. setsid() does create a new BC, but process B is the group leader, and the termination of B destroys the new context, so C winds up with an invalid BC. I'd appreciate more insight into this... Bill _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: should setsid() create new bootstrap context?
by Damien Sorresso 03 Apr '09

03 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Why would you expect this? -- Damien Sorresso BSD Engineering Apple Inc. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com On Apr 3, 2009, at 11:32 AM, Bill Janssen wrote: I think the root of my recent trouble with Darwin daemons is that I expected a call to setsid() to create a new bootstrap context. However, it doesn't seem to do that. Is that a bug in Darwin? smime.p7s

1 0

should setsid() create new bootstrap context?
by Bill Janssen 03 Apr '09

03 Apr '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I think the root of my recent trouble with Darwin daemons is that I expected a call to setsid() to create a new bootstrap context. However, it doesn't seem to do that. Is that a bug in Darwin? Bill _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0