site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Quinn; Thanks for the answer. Le 31 mai 07 à 11:32, Quinn a écrit : Boostrap port for the task is : 4107 Bootstrap's parent is : 779 Now recursing up : ... Recursion parent is : 779 #!/bin/bash StartupItemContext $@ Hope this was not too long; thanks again; (thick?) Serge. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGXs325EPeG5y7WPsRApCEAKD1COGNuT/QRzGxcsBX7QHjx39nCQCeJEP/ L2WlyAlQrIj4jN2wiJqKoks= =3MKF -----END PGP SIGNATURE----- _______________________________________________ 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... 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 : UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND

0 1 0 0 32 -1 28348 472 - S<s ?? 0:34.81 /sbin/launchd 86 4016 1 0 31 0 42780 2564 - Ss ?? 0:00.28 xgridagentd 0 4019 4016 0 31 0 29196 1212 - Ss ?? 0:00.03 /usr/libexec/xgrid/xgridagenthelper 1100 4045 4019 0 11 20 27812 1092 - SNs ?? 0:00.02 /bin/bash /var/xgrid/agent/tasks/HiqANG2L/working/./test.sh If I'm correct (which I'm absolutely NOT confident on), the namespace I'm running in should be connected to one of those processes ? The only info I got was that very likely the processes launched by xGrid get the same context as daemons/agents, hence the one that StartUpItemContext gives as well. I then tested a bit with bootstrap_parent() : launching a small program that is trying to go up the chain of bootstrap namespaces (the idea was to see how many of those were in between my process and the top one -the one having itself as parent-). From that I saw that "bootstrap_parent()" is only allowed if EUID=0 (at least in the xGrid and normal session context), so I made the program set-uid to root. Here are the results I get when running this program through xGrid (this is running as root, set-uid is set...) To me this looks like indeed the program launched by xGrid are running in the 'root' namespace... again if I'm not wrong that also means that I'll get the same context when executing my program using "StartUpItemContext" ? To me this also means that I can not believe that this particular bootstrap namespace is genuinly deactivated. 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 : 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. 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. 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()). But before getting into any of this, it would be a good idea to understand who is deactivating your bootstrap namespace and why. I don't know a lot about Xgrid, so I don't know the answer. Have you tried asking this over on xgrid-users? The only specific info I got on that issue was an indirect post (another participant in the list forwarded me some info he got from Ernest Prabhakar at apple) : For more information see <http://developer.apple.com/technotes/ tn2005/tn2083.html>. Tasks run under Xgrid have the same basic restrictions as daemons and agents. In Josh's particular case, he is getting error 1100, which is due to "deactivated bootstrap namespace". It looks to me like the agent is started in a particular bootstrap namespace (ie, an ssh session) and then that bootstrap namespace is deactivated (the ssh session ends.). I think Josh needs to start the agent in to root bootstrap namespace using the StartupItemContext tool, something like this: However in my case the agent is started on the node computers (running under OS-X server) via the Server Admin application, and as mentioned above it looks (to me at least) like they are in a bootstrap namespace which is it self parent (the reason why I guess it is the 'root'). S+E -- Quinn "The Eskimo!" <http://www.apple.com/ developer/> Apple Developer Relations, Developer Technical Support, Core OS/ Hardware [1] Well, there is bootstrap_unprivileged, but I've never seen it used. This email sent to site_archiver@lists.apple.com