Re: a Bootstrap Namespace question
Re: a Bootstrap Namespace question
- Subject: Re: a Bootstrap Namespace question
- From: Terry Lambert <email@hidden>
- Date: Thu, 31 May 2007 15:24:34 -0700
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 :
#!/bin/bash
StartupItemContext $@
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!
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden