site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com #!/bin/bash StartupItemContext $@ -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On May 31, 2007, at 6:30 AM, Serge Cohen wrote: Le 31 mai 07 à 11:32, Quinn a écrit : At 23:04 +0200 30/5/07, Serge Cohen wrote: PS : Another question is : is there anyway to see the difference between running in a deactivated namespace vs. an activated one but not having the necessary permissions to ope a port? Namespaces don't have permissions as such [1]: if you have a send right for a the namespace's, you can manipulate it. In my experience, a BOOTSTRAP_NOT_PRIVILEGED error always implies a deactivated namespace. I'll try to get further now. Sorry to be lengthy, but I have the impression that my reasonning gets wrong at some point and I hope that by putting it as clearly as possible here, you or someone else might be able to point me to my error : I've indeed first get to the xGrid mailing list (as I'm registered there for some time). I've seen there also a post about this type of java.awt problem before but did not find answer in the archive nor get any answer to my specific question (post http://lists.apple.com/archives/Xgrid-users/2007/May/msg00026.html ). Indeed the link to the technote I cite was found during this initial search.
From those readings, my first opinion was also that somehow launching a process within xGrid resulted in getting a deactivated namespace. I've tried to trace the process ids to check if eg. my process had PPID=1 (that's what happens in the ssh example of namespace deactivation, right); here is the result :
I think that it's pretty clear from the fact that the PPID is 1 that your process is being reparented to init (launchd), and that because of this, the intermediate process that started your process has exitted. This would destroy your bootstrap namespace, since a bootstrap namespace only lives as long as the last process that references it. This effectively means that, in order for your application to get a persistent reference, it needs to do so before it's parent process exits, and it gets reparented to launchd, for lack of its parent sticking around. Obviously, as you have discovered, to access the bootstrap namespace for the top level launchd, you have to be root. The normal way this is accomplished is by having a plist and activating your code via launchctl, and then dropping privilege after the fact - since launchd will be launching your application, at the behest of Xgrid, rather than launching it itself. Frankly, I don't know how Xgrid does session management, so I could not tell you how to do this, or at what points there are hooks in order to be able to get this done. You really need an Xgrid expert here, and explain to them your issue, in the context of needing access to the bootstrap namespace for an inherited parent. FWIW, you _could_ have Xgrid start a process, and then have that process _not_ exit, and start the Java process; this would give you access to the parents bootstrap namespace -- but since I don't know why in the heck anyone would need a bootstrap namespace in this context, I can't tell if this would be sufficient for your needs. The normal reason for needing one is to be able to rendezvous between processes in the namespace via Mach ports. Obviously, if you went this route, the parent process would need to wait for all its children to exit before it exits itself. At 23:04 +0200 30/5/07, Serge Cohen wrote: The only solution I've found so far is to write a small C program with set-uid to ROOT which first get to the root bootstrap namespace (the one attached to launchd process), then create a sub- namespace (using bootstrap_subset()) and then after going back to real-UID exec whatever I was trying to run. The best way to get into the root bootstrap is via <x-man-page://8/StartupItemContext
. Alternatively, you might look at bootstrap_parent (but I'd really prefer you use StartupItemContext).
I've tried that ... This requires that I have a set-uid shell script running StartupItemContext (because it can only be run as root). I had a short shell script installed on the node computers, with set- uid to root and containing basically something like : Actually, SUID shell scripts don't work by default on recent systems due to security considerations. You can make them work via a sysctl that must be executed as the root user in order to enable them (on a system-wide basis), but I believe that this change went into all 10.4.x systems a while back. I did not managed to get that running, indeed StartupItemContext was complaining that it should be run as root... I have to admit I've not spent to much time on that because I was not really happy to have a set-uid shell script intstalled on the machines. This is what's expected, as the SUID-ness of shells scripts is no longer valid by default. You'd need to write a small wrapper program. Also , going further in this direction means that the program run by xGrid will run in the top namespace; the result is that 'All subsequent Mach port bootstrap registrations perfomed by the program will be visible system-wide.' which I'd really rather avoid. That is why I tried to make a sub-namespace under the top one so that whatever the process run by xGrid do, it can NOT affect any other parts of the system. Again, you're going to need an Xgrid expert to tell you how new processes are started under Xgrid to get to where you need to be. My personal preferrence, since this application is not graphical, would be to avoid any IPC mechanism that expects access to a bootstrap namespace in the first place (but, again, that may not be good enough for your purposes). I'd strongly recommend against getting launchd's bootstrap. While this will give you the root bootstrap on current systems, it probably won't on future systems. Sorry I was not clear here : indeed I'm using the 'top' namespace : recursing using bootstrap_parent() until the current is equal to its parent. Then I do a sub-namespace (using bootstrap_subset()). Sounds like a wrapper parent process is your best bet, if you absolutely _must_ have this... my best advice would be to go back to the Xgrid list and ask them how processes are started up, and how you maintain access to the bootstrap namespace (which will lead to them asking you why you need it). Good luck, and let us know what they say so it gets archived over here, as well! This email sent to site_archiver@lists.apple.com