Comments below...
Pier Fumagalli wrote:
>
> "Patrick Luby" <[EMAIL PROTECTED]> wrote:
>
> > Maybe I should clarify what I am trying to do. I am trying to enable the use
> > of setuid() within the existing Tomcat startup process (i.e. shell scripts). I
> > definitely like your native launcher and the more I look at it, the more I
> > like its sophisticated function. I just want to make the setuid() call
> > available even if I haven't startup Tomcat using your native launcher. The way
> > to do that is to use the Java->JNI method of creating a shared library that
> > contains a function with a name that matches a demangled version of a "public
> > native" Java method. Then, when Tomcat is started via a script (as it does
> > now), the StandardServer class can do the following:
> >
> > - Invoke System.loadLibrary()
> > - Bind all of the ports (if you are root, you can bind to ports <= 1024)
> > - If we are root, invoke a "public native" method that Java maps to the C
> > function contained in the shared library. The C function would contain
> > the setuid() C call to change the Java process to a non-root user
>
> Hmm... I don't like it, but now I got what you're trying to do...
>
> > The above method effectively does the same thing as your native launcher. The
> > only difference is that I thought it might be a may to get your setuid code
> > into the standard Tomcat installations
>
> The only code working is within Tomcat, and it's there already... Look at
> the API changes in the Connector I pointed out yesterday, and at the
> different Embedded solutions (like the one Remy did for Win32 services)...
> The java code is there, the entry points are all there... All we need is a
> JNI wrapper/invocator which loads the VM, calls initialize(), sets the
> UID/GID, calls(start), wait for a signal, calls stop()...
>
> > much sooner since my proposed approach
> > is compatible with the existing Tomcat configuration and startup.
>
> Given that I don't even have time to blow my nose ATM, I won't argue on
> implementation, but just comment on the idea... Calling setuid() from Java
> is crap (design wise), because it's against all design principles Java is
> based on... It's not portable, and there is already a much better
> alternative that is completely platform independant... Someone just needs to
> make it work (I'd give a one-week time to a guy like you to make it run :)
>
> > I think the only changes to support my proposed approach in your native code
> > are the following:
> >
> > - Add a "public static native" method in DaemonLoader.java
> > - Create a DaemonLoader.h file using javah
> > - Implement the setuid() calls for the function defined in DaemonLoader.h
> > in DaemonLoader.c. Specifically, I could just move the child process' code
> > in the checkuser function here so that there is not duplication of code.
> > - Add compiling and linking of DaemonLoader.c into a shared library that the
> > Java System.loadLibrary() call can handle.
> > - Add calling of this "public static native" method from Tomcat's
> > StandardService.initialize() method (i.e. after all ports have been bound).
>
> Also, what I don't like is the pollution of Java code with calls to specific
> methods which are System dependant. It's true you can implement a void
> "setuid" on platforms where it's not supported, but design wide is crap
> (IMO).
>
> >> Also, if you need to do some callbacks from Java into our native C code, the
> >> easiest thing is to register those right after invoking CreateJavaVM in JNI
> >> (and it works), rather than relying on an external library...
> >
> > I was thinking that once we have the above method implemented, we could try
> > replacing the existing scripts with the native launchers. At that point, the
> > System.loadLibrary() call in Tomcat could be removed since the native launcher
> > could register the JNI C function that the "public native" method maps to.
> >
> > What do you think of the above approach?
>
> As I said, I'm more on the approach I outlined several times here and on the
> JSR-096 mailing list my preferred approach to the problem is to create a
> wrapper around the Java Virtual Machine and an API defining the lifecycle of
> a Daemon process...
>
> Not in many details, the API I would love to see is (at the end) something
> like:
>
> public interface Daemon extends Runnable {
> public void init(...);
> public void destroy();
> }
>
> Init() can be called as root if the process is started as root, otherwise,
> it gets called at whoever, after init() returns cleanly, the main thread
> starts sleeping and waiting for signals, a new thread is created and this
> calls the run() method in Daemon (extends runnable!)...
I imagine it's at some point in there that the UID can get changed
to some non-root value?
One benefit to Pier's approach that I haven't seen mentioned is of
particular concern to paranoid sysadmins (redundant?). If I run
tomcat with a security manager I should be able to turn off native
code completely in the policy file. Then I only need to audit the
source code for the launcher to verify that my system is safe (within
the boundaries of my Java policy file). It's one of the nice things
about Java servers; a decent security model. Of course, it would be
nice if Catalina shipped with a better default security policy, but
that's a topic for another day. ;)
-Paul
>
> To stop the whole kid, the destroy() method is called by the main thread
> after this receives a signal. The destroy method implementation will stop
> the thread in run(), clean all it has to clean, and return.
>
> When the thread going in run() returns, we simply call our exit() and
> terminate the JVM process....
>
> IMO, this is the most portable thing, and design wise is kinda cool, as we
> "extend" the idea of a Runnable which is an object associated with a thread.
> A process is nothing else that a thread of execution associated with some
> memory, so, there's quite a nice parallel....
>
> People might like it, people might not... Since I don't have time ATM , it's
> up to you folks...
>
> Pier
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
