You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Remy Maucherat <re...@apache.org> on 2002/02/19 07:19:48 UTC
[Daemon] New commons component
Hi,
I've added a new component to the commons subproject (in the sandbox), which
is designed to allow Java programs to run as native operating system daemons
(services under Windows NT).
Because of its nature, this component contains a significant amount of
native code.
This component API and Unix code was developed by Pier Fumagalli as part of
the Tomcat 4 project, but is fully generic and not tied in any way to
Tomcat, so other server side applications may find it useful.
The NT service code and related utilities were written by Jean-Frederic
Clere.
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Nick Betteridge <n....@syntactics.com>.
Patrick Luby wrote:
>
> Remy,
>
> This is great news!
>
> I scanned through the Unix code and noticed that it uses the chmod'ing
> executables with setuid bits instead of performing a JNI call to the setuid()
> and seteuid() C functions before and after binding of a ServerSocket (i.e. the
> place you should need root access if you are binding to ports 1 through 1024).
> This type of approach eliminates the need for a controller and slave process.
>
> If there is interest out there, I can work up a proposal for implementing this
> type of setuid functionality. I has been a year or two since I did my last JNI
> coding, but I should be able to dig up some setuid code that I have done in the past.
>
There is interest out there!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Patrick Luby <pa...@sun.com> wrote:
> Remy,
>
> Remy Maucherat wrote:
>>
>> At the moment, it is only a NT service, I think. The exe wrapper can (and
>> probably should) do both.
>
> I will admit that I am no Windows expert, but can't you just have a main()
> function that invokes start service code. Shutdown would be a little trickier
> as
> you need to send it a signal or some other event.
Under WindoSH either the "stop" button on the "services" panel, or the
"CTRL-C" trap from the command line are trappable just like signals in
unix.. When we trap those events, we can easily forward them thru JNI to the
VM process on some methods...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
>
> At the moment, it is only a NT service, I think. The exe wrapper can (and
> probably should) do both.
I will admit that I am no Windows expert, but can't you just have a main()
function that invokes start service code. Shutdown would be a little trickier as
you need to send it a signal or some other event.
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> Remy,
>
> Remy Maucherat wrote:
> >
> > I agree with Pier here. I think we should only try to implement daemon
> > fnctionality using the appropriate wrapper. Implmenting it with standard
> > Tomcat using scripts is a nasty hack.
> > Somehow, Patrick doesn't seem to like my BootstrapService (which works
> > perfectly well; it's even been in use for a long time through the NT
service
> > which ships with the Windows installer) :-(
>
> I admit it: I was trying to implement a hack. I am definitely warming up
to the
> idea of jumping straight into Pier's scripts. After all of this
discussion, it
> doesn't seem to be so much work to switch to a native launcher to
implement the
> setuid() stuff.
Wait, Costin did cast his vote in your favor ;-)
> Plus, I agree with Remy that the use of shell scripts to launch Tomcat is
a bit
> nasty. I like the idea of using Pier's launcher (I assume the Windows
native
> code has a native launcher as well?)
*cough*
Well, let's say the current Windows code needs Cygwin and the jsvc "Unix"
wrapper at the moment ;-)
Obviously, contributors are needed to implment a Win native JNI based
wrapper :-D
> to be able to start Tomcat via a
> double-click on an executable and no MS-DOS window on Windows.
At the moment, it is only a NT service, I think. The exe wrapper can (and
probably should) do both.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Patrick Luby <pa...@sun.com> wrote:
> I admit it: I was trying to implement a hack. I am definitely warming up to
> the idea of jumping straight into Pier's scripts. After all of this
> discussion, it doesn't seem to be so much work to switch to a native launcher
> to implement the setuid() stuff.
See the code, move SETUID after INITIALIZE() and it should automagically
work (well, maybe not all calls are implemented, but it's fairly
straightforward).
> Plus, I agree with Remy that the use of shell scripts to launch Tomcat is a
> bit nasty. I like the idea of using Pier's launcher (I assume the Windows
> native code has a native launcher as well?) to be able to start Tomcat via a
> double-click on an executable and no MS-DOS window on Windows.
Basically AlexandriaSC and my stuff do the same thing... In mine there is
also the hack for the setuid (or it should be there)...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
>
> I agree with Pier here. I think we should only try to implement daemon
> fnctionality using the appropriate wrapper. Implmenting it with standard
> Tomcat using scripts is a nasty hack.
> Somehow, Patrick doesn't seem to like my BootstrapService (which works
> perfectly well; it's even been in use for a long time through the NT service
> which ships with the Windows installer) :-(
>
I admit it: I was trying to implement a hack. I am definitely warming up to the
idea of jumping straight into Pier's scripts. After all of this discussion, it
doesn't seem to be so much work to switch to a native launcher to implement the
setuid() stuff.
Plus, I agree with Remy that the use of shell scripts to launch Tomcat is a bit
nasty. I like the idea of using Pier's launcher (I assume the Windows native
code has a native launcher as well?) to be able to start Tomcat via a
double-click on an executable and no MS-DOS window on Windows.
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
> I agree with Pier here. I think we should only try to implement daemon
> fnctionality using the appropriate wrapper. Implmenting it with standard
> Tomcat using scripts is a nasty hack.
> Somehow, Patrick doesn't seem to like my BootstrapService (which works
> perfectly well; it's even been in use for a long time through the NT service
> which ships with the Windows installer) :-(
I like your approach on it (well AlexandriaSC's approach)... That's when we
got crummed on on JCP-096, they didn't want to "keep it simple"...
> Question: How is JSR 96 doing ? Did you leave the EG because the lead is
> impossible to work with ? What I mean is: is there still hope that the final
> spec is decent ?
No. We fought throughout the whole EG to have a decent spec, and the Spec
Lead completely ignored all our comments (not only Apache's but of ALL
experts). He came out with a spec which sucks, as it leaves the handling of
the JVM process lifecycle into an unspecified behavior.
We didn't agree on putting it on to the next stage of the JCP (as expert
group), but he did it anyway. Now what the ASF is going to do is to vote -1
on its publication in "community review", and hopefully block it there since
we have the support of most of the JSR-096 expert group (apart from the spec
lead and the two folks working in his company on the EG)...
JSR-906 will hopefully never come to a final javax.... API (or at least
that's what the expert group is trying to do).
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> "Patrick Luby" <pa...@sun.com> 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 agree with Pier here. I think we should only try to implement daemon
fnctionality using the appropriate wrapper. Implmenting it with standard
Tomcat using scripts is a nasty hack.
Somehow, Patrick doesn't seem to like my BootstrapService (which works
perfectly well; it's even been in use for a long time through the NT service
which ships with the Windows installer) :-(
> 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!)...
>
> 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...
Question: How is JSR 96 doing ? Did you leave the EG because the lead is
impossible to work with ? What I mean is: is there still hope that the final
spec is decent ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Wed, 20 Feb 2002, Paul Speed wrote:
> 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. ;)
As I said, if you want port 80 you need root until you open the
port.
If you really want, you can write a small "RootLoader" that
will just open 80 and chuid, and the connector use the
opened Socket. And in policy specify only the RootLoader
class as allowed to load native.
Costin
>
> -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: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Paul Speed <pa...@objectsciences.com>.
Comments below...
Pier Fumagalli wrote:
>
> "Patrick Luby" <pa...@sun.com> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: /servlets/ URL path...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 20 Feb 2002, Pier Fumagalli wrote:
> Date: Wed, 20 Feb 2002 17:23:11 +0000
> From: Pier Fumagalli <pi...@betaversion.org>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: /servlets/ URL path...
>
> When I invoke a servlet such as
>
> http://localhost/application/servlets/HelloWorld
>
> WHO actually defines that /servlets/ is associated with my classes? Is it
> defined somewhere in the spec or is it a feature of Tomcat (in 4.0 it's the
> InvokerServlet, IIRC)
>
It's not in the spec -- it's a feature of Tomcat and many other servlet
containers. For Tomcat 4 in particular, its defined in "conf/web.xml"
which establishes default characteristics of all webapps. (Note that it's
mapped to "/servlet/*" not /servlets/*" though).
> Cheerios!
>
> Pier
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: /servlets/ URL path...
Posted by Filip Hanik <ma...@filip.net>.
It is not in the spec if I remember correctly.
It is a feature of tomcat so that you don't have to register servlets in
web.xml
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
filip@filip.net
www.filip.net
>-----Original Message-----
>From: Pier Fumagalli [mailto:pier@betaversion.org]
>Sent: Wednesday, February 20, 2002 9:23 AM
>To: Tomcat Developers List
>Subject: /servlets/ URL path...
>
>
>When I invoke a servlet such as
>
>http://localhost/application/servlets/HelloWorld
>
>WHO actually defines that /servlets/ is associated with my classes? Is it
>defined somewhere in the spec or is it a feature of Tomcat (in 4.0 it's the
>InvokerServlet, IIRC)
>
>Cheerios!
>
> Pier
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
/servlets/ URL path...
Posted by Pier Fumagalli <pi...@betaversion.org>.
When I invoke a servlet such as
http://localhost/application/servlets/HelloWorld
WHO actually defines that /servlets/ is associated with my classes? Is it
defined somewhere in the spec or is it a feature of Tomcat (in 4.0 it's the
InvokerServlet, IIRC)
Cheerios!
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
>
> 1. I think combining the wrappers ( any of them ) with the
> platform-specific native code used inside tomcat is _bad_.
> One of the good things about tomcat is that it can be started/mebedded
> in many different ways. Creating a small jni library is quite trivial -
> MacOS may be different, but I'm sure they provide a way and we can
> support it ( if we want in-process and unix sockets there we'll
> have to do it anyway - that's jni based ). Keep them separated -
> it's more flexible.
I have already wrote a quick test on Mac OS X. It works just like all other
platforms. The only difference is that you need to link your shared library with
"-bundle" and name it libxxxx.jnilib instead of libxxxx.so. After that,
System.loadLibrary("xxxx") will load the library. You don't even need to link to
any of the JVM's libraries to do this.
>
> 2. The 'normal' way to do this, used by all unix daemons, by
> all other java servers ( including JavaWebServer and any other
> containers except tomcat ) is to use a (jni) call to chuid.
> It works, it's tested and clean.
> I'm sure this can be obfuscated or done using whatever callbacks
> mechanism ( opening all the resource in the wrapper, etc) , but doing it
> in the natural way is better IMHO.
This is why I was pursuing this approach for the last 2 days. I have seen this
type of code way back when I was porting the Java Web Server's JNI code to
HP-UX, AIX, and DEC Unix a few years back. Also, I believe that Apache follows
this same logic path (although it doesn't need JNI to get to the C function, of course).
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Wed, 20 Feb 2002, Patrick Luby wrote:
> > The uid must be changed after it start listening, like any unix program
> > does. And the wrapper/invocator is just one way to start tomcat - I like
> > the flexibility on startup.
> >
>
> This is very true and was the reason I was pursuing the "public native" method
> approach. But Pier mentioned and passing a callback function to the JVM when he
> starts it. Maybe Pier could elaborate on this process? Basically, for Pier's
> callback approach to work, the callback function would need to be tied to
> invocation of the StandardServer.initialize() method. I haven't used any
> callbacks like he describes so I am curious about the mechanics.
1. I think combining the wrappers ( any of them ) with the
platform-specific native code used inside tomcat is _bad_.
One of the good things about tomcat is that it can be started/mebedded
in many different ways. Creating a small jni library is quite trivial -
MacOS may be different, but I'm sure they provide a way and we can
support it ( if we want in-process and unix sockets there we'll
have to do it anyway - that's jni based ). Keep them separated -
it's more flexible.
2. The 'normal' way to do this, used by all unix daemons, by
all other java servers ( including JavaWebServer and any other
containers except tomcat ) is to use a (jni) call to chuid.
It works, it's tested and clean.
I'm sure this can be obfuscated or done using whatever callbacks
mechanism ( opening all the resource in the wrapper, etc) , but doing it
in the natural way is better IMHO.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
>
> > Pier,
> >
> > I took a quick look at the code and found the RegisterNative function.
> This
> > looks like an interesting feature. I also found the same function in your
> > daemons code. The picture is becoming much clearer.
> >
> > Let me try to get it working in the next few days with the callback
> function set
> > to invoke setuid() and have the callback invoke (via Java reflection since
> it
> > won't be there on Windows or standalone start.
> >
> > If I can get this to work, I will post the patches first so that all can
> > inspect. Now that I understand this approach, it basically seems to work
> through
> > the same logical steps (from a Tomcat Java code) perspective as invoking
> the
> > callback function via JNI.
> >
> > In your approach, the function is preloaded for Java (no
> System.loadLibrary()
> > required) and the Java code invokes the function like any other method (it
> just
> > happens that the method doesn't exist at compile time but only at
> runtime).
>
> There are only two "native daemon" configurations I'm interested in:
> - embedded in Apache 2 with a JNI connector
> - used through jsvc on Unix, and some similar wrapper on Win NT (or jsvc.exe
> using Cygwin; it works :))
The jsvc.exe is started by a "monitor process". The monitor process is win32
code. jsvc uses Cygwin (That was a very fast to get it working).
The signals in windoze are done via event and thread. But only SIGTERM is
supported for the moment.
>
> With Daemon, from the C code, all you have to do is, as Pier pointed out:
> - Call init
> - Use setuid to downgrade to nobody
> - Call start
> - Wait for a stop signal, at which point you call stop
>
> At this point, I do not see the need for any use of native code from the
> Java side.
Right we need JAVA code in native code ;-)
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Thu, 21 Feb 2002, Patrick Luby wrote:
> > Ok, I'll send then an email.
> > And would participate in the project ?
>
> If it allows me to start Tomcat and all of the other tools (e.g. jspc, etc.)
> without shell or batch scripts, count me in.
It allows to start tomcat or any server process, monitors
it and restarts it if it dies. And it provide the same interface on
windows and unix, integrating in the service manager for windows
and using a C deamon on unix.
It can be used to start all other tools - with all the control you
want ( like setting classpaths, JVM parameters, etc ).
BTW, tomcat already provide a way to start itself without any
scripts ( i.e. java -jar tomcat.jar / java -jar catalina.jar ),
and in 3.3 most tools can be started this way.
Creating few additional executable jars for jspc, etc is
quite easy and doesn't require any native code. You can use
some of the 3.3 introspection code that will 'guess' the
CLASSPATH from the command line and construct the class path -
it is almost completely equivalent with tomcat.sh.
( the only missing part is that you can't set jvm parameters
after you started, but that can be solved with an exec ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
>
> Ok, I'll send then an email.
> And would participate in the project ?
If it allows me to start Tomcat and all of the other tools (e.g. jspc, etc.)
without shell or batch scripts, count me in.
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> On Thu, 21 Feb 2002, Remy Maucherat wrote:
>
> > Don't go on a rant just because the interface has an init method, and
> > vaguely implies how some of the design of the server should be (and also
of
> > course because it's an interface), please ;-)
> > I'm surprised you're not pushing to make it an abstract class, BTW.
>
> :-)
>
> I'm not even saying that init() is bad - it's a clever idea.
> I was just saying it's not the only solution and in some
> cases you may want more control over when and to what user
> id you change your process to.
>
> What Patrick proposed initially with a simple JNI call is
> a valid solution ( and maybe more flexible ).
>
>
> BTW: I don't like 'hairy' interfaces that will never have more
> than a single implementation anyway ( because too much depend
> on the actual Base class behavior ), and where everyone
> will extend the Base class anyway.
>
> For Deamon - 4 methods is not too much, I love what's clean and
> simple.
Yes, I want that one as an interface, since you may want to extend another
object to implement the daemon functionality.
> I don't like the 4 fail methods in DeamonController,
> I think DaemonContext should be a real class, DeamonListener
> needs a pair DeamonEvent and some methods, and so on.
Well, if you look at wrapper, it's simpler (a bit too simple IMO).
The 4 fails look too much indeed.
> If the JSR is going to fail ( or if we decide to not try
> to implement whatever they release, if they do release it ),
Apparently, they're not nice guys. Plus, it has a good chance at getting
shot down by the JCP, since the whole EG seems really upset.
> then I think we should discuss and review some of the API
> details - now we're not going to have any nasty 'expert lead'
> and we can do a real open source Daemon ( eventually with
> the contribution of the wrapper authors, who are pretty good
> 'experts' ).
Obviously. the Java part of the API is ridiculously small, and implemented
(most of the time) in one single wrapper class. So here, we can redesign the
API often during the alpha stages without many problems :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Fri, 22 Feb 2002, Pier Fumagalli wrote:
> >>> wheel ? The daemon requires using an init()-like method and a certain
> >>> architecture - which the other solution doesn't.
> >>
> >> ?
> >> I wonder what prevents you from having an empty init method, and then doing
> >> whatever JNI calls you want suring start.
> >
> > Nothing - that's what I'm saying, both are good solutions and we
> > shouldn't exclude one because the other does the same thing.
>
> That's whay _you_ say... I don't think they are _both_ good solutions... One
> is nice, the other sucks (calling setuid() from Java is the sucky one)...
All other people developing servers seem to say the same thing as I do.
And what sucks ( IMHO ) is the attitude 'my solution is perfect, all
other suck, so my solution should be used exclusively' ( sort of
what the IOC fanatics keep saying )
And that for something that has obvious limitations and doesn't provide
too much extra security. The only thing that protects you is the sandbox,
and most people are not using it. Without sandbox anyone hacking in
a webapp can change server.xml, place code in common/, add a dummy
connector with an init() doing 'rm -rf /' and restart the server.
Not to mention the limitations in flexibility ( can you set the
user in server.xml ? ). Forcing people to design their application in a
certain way ( can it support 'trusted apps' acting as connectors ? ). Or
start the server only through the daemon ( what if I want to use
the wrapper, which today has a far better implementation ? ).
The idea of changing the uid in a 'starter' program is not new - inetd
is doing that for ages. Except that it also aquires the priviledged
port and pass it to the app during the exec, it doesn't call any
application code as root. And again all applications must be designed to
support 'intetd' mode.
I'm not saying it shouldn't be used - or that it sucks. It may
have some uses. Even tought I can't find any - as long as you do
execute init() as root, you get no security at all ( maybe an
illusion ), and you replace a clean JNI ( java calling C is something
reasonably easy ) with invocation API ( c->java), which is
extremely tricky ( you must set LD_LIBRARY_PATH on certain
systems/OSes, be very carefull with the signals, etc ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Thu, 21 Feb 2002, Remy Maucherat wrote:
>
>>> Because there is not 'a single ( or only ) good way to start tomcat'.
>>>
>>> If doing a JNI call works and is a good solution, why reinventing the
>>> wheel ? The daemon requires using an init()-like method and a certain
>>> architecture - which the other solution doesn't.
>>
>> ?
>> I wonder what prevents you from having an empty init method, and then doing
>> whatever JNI calls you want suring start.
>
> Nothing - that's what I'm saying, both are good solutions and we
> shouldn't exclude one because the other does the same thing.
That's whay _you_ say... I don't think they are _both_ good solutions... One
is nice, the other sucks (calling setuid() from Java is the sucky one)...
But that's MO, of course... And since MO was never listened to, I don't care
:)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Thu, 21 Feb 2002, Remy Maucherat wrote:
> > Because there is not 'a single ( or only ) good way to start tomcat'.
> >
> > If doing a JNI call works and is a good solution, why reinventing the
> > wheel ? The daemon requires using an init()-like method and a certain
> > architecture - which the other solution doesn't.
>
> ?
> I wonder what prevents you from having an empty init method, and then doing
> whatever JNI calls you want suring start.
Nothing - that's what I'm saying, both are good solutions and we
shouldn't exclude one because the other does the same thing.
If you start a process that does use the init() API to get all
resources, and you are using the daemon to start it - that's
probably a perfect solution.
If you start a process that doesn't fit this model, or you
want to use a different starter, or if you just want to
explicitely call setUid based on some parameters inside
server.xml ( and not in the wrapper properties ) or even
set it conditionally or anything else - a JNI call is a better
solution.
( except that 'better' than 'perfect' doesn't make sense :-).
> Don't go on a rant just because the interface has an init method, and
> vaguely implies how some of the design of the server should be (and also of
> course because it's an interface), please ;-)
> I'm surprised you're not pushing to make it an abstract class, BTW.
:-)
I'm not even saying that init() is bad - it's a clever idea.
I was just saying it's not the only solution and in some
cases you may want more control over when and to what user
id you change your process to.
What Patrick proposed initially with a simple JNI call is
a valid solution ( and maybe more flexible ).
BTW: I don't like 'hairy' interfaces that will never have more
than a single implementation anyway ( because too much depend
on the actual Base class behavior ), and where everyone
will extend the Base class anyway.
For Deamon - 4 methods is not too much, I love what's clean and
simple.
I don't like the 4 fail methods in DeamonController,
I think DaemonContext should be a real class, DeamonListener
needs a pair DeamonEvent and some methods, and so on.
If the JSR is going to fail ( or if we decide to not try
to implement whatever they release, if they do release it ),
then I think we should discuss and review some of the API
details - now we're not going to have any nasty 'expert lead'
and we can do a real open source Daemon ( eventually with
the contribution of the wrapper authors, who are pretty good
'experts' ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> On Thu, 21 Feb 2002, Remy Maucherat wrote:
>
> > > However it's not the only way to do things - and I prefer to not
> > > depend on the wrapper that starts tomcat to do it ( there are
> > > many other good ways to start tomcat without requiring the daemon )
> >
> > If it's "good ways to start tomcat" as a daemon, then I disagree (except
if
> > it's when embedded through JNI in Apache). At best, it will work as good
as
> > with the daemon code, so why bother ?
>
> Because there is not 'a single ( or only ) good way to start tomcat'.
>
> If doing a JNI call works and is a good solution, why reinventing the
> wheel ? The daemon requires using an init()-like method and a certain
> architecture - which the other solution doesn't.
?
I wonder what prevents you from having an empty init method, and then doing
whatever JNI calls you want suring start.
> Even for tomcat4.0,
> it would make my life more difficult if jk needs to do something as
> root ( given that I'm trying to make jk a self-contained trusted
> application that doesn't require changes in server.xml ).
>
> In general, I don't like the 'starter' to impose constraints or
> dictate the design of the application, especially when the same
> feature can be implemented without this constraint and in a
> simpler manner. I don't like the container to impose too
> many constraints on the application either.
>
> It's the old "push versus pull" - or IOC versus 'straight'
> programming. I have nothing against IOC as long as it
> doesn't try to force to be the 'only' way.
Don't go on a rant just because the interface has an init method, and
vaguely implies how some of the design of the server should be (and also of
course because it's an interface), please ;-)
I'm surprised you're not pushing to make it an abstract class, BTW.
> > Ok, I'll send then an email.
> > And would participate in the project ?
>
> Yes, I think the 'wrapper' is very good and promissing. I already sent
> them an email, but if you want to take care of this - it's great.
I did send them an email too (writing the reply now).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Thu, 21 Feb 2002, Remy Maucherat wrote:
> > However it's not the only way to do things - and I prefer to not
> > depend on the wrapper that starts tomcat to do it ( there are
> > many other good ways to start tomcat without requiring the daemon )
>
> If it's "good ways to start tomcat" as a daemon, then I disagree (except if
> it's when embedded through JNI in Apache). At best, it will work as good as
> with the daemon code, so why bother ?
Because there is not 'a single ( or only ) good way to start tomcat'.
If doing a JNI call works and is a good solution, why reinventing the
wheel ? The daemon requires using an init()-like method and a certain
architecture - which the other solution doesn't. Even for tomcat4.0,
it would make my life more difficult if jk needs to do something as
root ( given that I'm trying to make jk a self-contained trusted
application that doesn't require changes in server.xml ).
In general, I don't like the 'starter' to impose constraints or
dictate the design of the application, especially when the same
feature can be implemented without this constraint and in a
simpler manner. I don't like the container to impose too
many constraints on the application either.
It's the old "push versus pull" - or IOC versus 'straight'
programming. I have nothing against IOC as long as it
doesn't try to force to be the 'only' way.
> Ok, I'll send then an email.
> And would participate in the project ?
Yes, I think the 'wrapper' is very good and promissing. I already sent
them an email, but if you want to take care of this - it's great.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> On Thu, 21 Feb 2002, Remy Maucherat wrote:
>
> > I didn't write either APIs. Someone on the commons mentioned this
project,
> > so I went there. It seems to me that omitting the 'init' method is a
glaring
> > omission.
> > The native part of the code looks miles ahead of damon's code, though :)
>
> Having an init() method is a good idea, and the way deamon works is not
> bad - it's an usefull feature.
>
> However it's not the only way to do things - and I prefer to not
> depend on the wrapper that starts tomcat to do it ( there are
> many other good ways to start tomcat without requiring the daemon )
If it's "good ways to start tomcat" as a daemon, then I disagree (except if
it's when embedded through JNI in Apache). At best, it will work as good as
with the daemon code, so why bother ?
> > The project looks inactive, so maybe it would be possible to talk to the
> > authors and merge ?
> >
> > Eventually, this could end up as a top level project at Jakarta (seems
> > useful enough functionality for me).
>
> A big +1 from me.
>
> It can start in commons, I think would be a _very_ usefull component.
> The more I look at the wrapper code, the more I like it.
Ok, I'll send then an email.
And would participate in the project ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Thu, 21 Feb 2002, Remy Maucherat wrote:
> I didn't write either APIs. Someone on the commons mentioned this project,
> so I went there. It seems to me that omitting the 'init' method is a glaring
> omission.
> The native part of the code looks miles ahead of damon's code, though :)
Having an init() method is a good idea, and the way deamon works is not
bad - it's an usefull feature.
However it's not the only way to do things - and I prefer to not
depend on the wrapper that starts tomcat to do it ( there are
many other good ways to start tomcat without requiring the daemon )
> The project looks inactive, so maybe it would be possible to talk to the
> authors and merge ?
>
> Eventually, this could end up as a top level project at Jakarta (seems
> useful enough functionality for me).
A big +1 from me.
It can start in commons, I think would be a _very_ usefull component.
The more I look at the wrapper code, the more I like it.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> On Wed, 20 Feb 2002, Bill Barker wrote:
>
> > IMHO, beyond Pier's and Remy's requirements, this will never fly in the
real
> > world. I don't see any way that you are going to convince webmasters
> > (including me) to relax the sandbox enough to allow this.
>
> Bill, this solution is what all servlet container are doing ( except
> tomcat ). Look at any servlet container that runs on port 80 on unix, and
> you'll find a small JNI library that change the user id.
>
> For tomcat3.x - we don't need that too much because it's far better to
> start as non-root from the beginning, and use a real web server on 80.
> But assuming we would want to, I'm not sure 'deamon' would work without
> major modifications in tomcat ( to implement its model ), and I'm not
> sure how many other applications will fit the model, and I'm
> not sure I want to make the 'daemon' a requirement. I like
> the sourceforge's wrapper a lot, that's what I would use,
> and I know many other solutions in use for starting and keeping
> java programms alive that don't impose such requirements.
I didn't write either APIs. Someone on the commons mentioned this project,
so I went there. It seems to me that omitting the 'init' method is a glaring
omission.
The native part of the code looks miles ahead of damon's code, though :)
The project looks inactive, so maybe it would be possible to talk to the
authors and merge ?
Eventually, this could end up as a top level project at Jakarta (seems
useful enough functionality for me).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Wed, 20 Feb 2002, Bill Barker wrote:
> IMHO, beyond Pier's and Remy's requirements, this will never fly in the real
> world. I don't see any way that you are going to convince webmasters
> (including me) to relax the sandbox enough to allow this.
Bill, this solution is what all servlet container are doing ( except
tomcat ). Look at any servlet container that runs on port 80 on unix, and
you'll find a small JNI library that change the user id.
For tomcat3.x - we don't need that too much because it's far better to
start as non-root from the beginning, and use a real web server on 80.
But assuming we would want to, I'm not sure 'deamon' would work without
major modifications in tomcat ( to implement its model ), and I'm not
sure how many other applications will fit the model, and I'm
not sure I want to make the 'daemon' a requirement. I like
the sourceforge's wrapper a lot, that's what I would use,
and I know many other solutions in use for starting and keeping
java programms alive that don't impose such requirements.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Bill Barker <wb...@wilshire.com>.
> Native code is used and needed by jk, and 'wrapping' APR is one
> of my current goals - it'll provide much more than chuid.
> I think it's much cleaner to use 'normal' JNI when you want
> to call C code from java, so I'll stick with this solution.
IMHO, beyond Pier's and Remy's requirements, this will never fly in the real
world. I don't see any way that you are going to convince webmasters
(including me) to relax the sandbox enough to allow this.
I'm committed enough to the principal of "software Darwinism" that I see no
point in voting against this, however.
>
>
> Costin
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Thu, 21 Feb 2002, Pier Fumagalli wrote:
> > There are only two "native daemon" configurations I'm interested in:
> > - embedded in Apache 2 with a JNI connector
>
> That's feasible, but requires major changes in Tomcat 4.0
It should work fine with jk2, no change is needed in tomcat ( it's the
same code used for ajp ).
What's holding this is the multi-process aspect of Apache, and to
solve this we need to improve the configuration ( so Apache can be treated
as a 'natural' loadbalancing ).
> > At this point, I do not see the need for any use of native code from the
> > Java side.
>
> Agreed wholeheartly...
I disagree, but it doesn't matter - both can be implemented.
Native code is used and needed by jk, and 'wrapping' APR is one
of my current goals - it'll provide much more than chuid.
I think it's much cleaner to use 'normal' JNI when you want
to call C code from java, so I'll stick with this solution.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
> There are only two "native daemon" configurations I'm interested in:
> - embedded in Apache 2 with a JNI connector
That's feasible, but requires major changes in Tomcat 4.0
> - used through jsvc on Unix, and some similar wrapper on Win NT (or jsvc.exe
> using Cygwin; it works :))
Yeah, and that's what we wanted to do in JSR-096, but the spec lead decided
he wanted to reinvent JMX...
> With Daemon, from the C code, all you have to do is, as Pier pointed out:
> - Call init
> - Use setuid to downgrade to nobody
> - Call start
> - Wait for a stop signal, at which point you call stop
>
> At this point, I do not see the need for any use of native code from the
> Java side.
Agreed wholeheartly...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> Pier,
>
> I took a quick look at the code and found the RegisterNative function.
This
> looks like an interesting feature. I also found the same function in your
> daemons code. The picture is becoming much clearer.
>
> Let me try to get it working in the next few days with the callback
function set
> to invoke setuid() and have the callback invoke (via Java reflection since
it
> won't be there on Windows or standalone start.
>
> If I can get this to work, I will post the patches first so that all can
> inspect. Now that I understand this approach, it basically seems to work
through
> the same logical steps (from a Tomcat Java code) perspective as invoking
the
> callback function via JNI.
>
> In your approach, the function is preloaded for Java (no
System.loadLibrary()
> required) and the Java code invokes the function like any other method (it
just
> happens that the method doesn't exist at compile time but only at
runtime).
There are only two "native daemon" configurations I'm interested in:
- embedded in Apache 2 with a JNI connector
- used through jsvc on Unix, and some similar wrapper on Win NT (or jsvc.exe
using Cygwin; it works :))
With Daemon, from the C code, all you have to do is, as Pier pointed out:
- Call init
- Use setuid to downgrade to nobody
- Call start
- Wait for a stop signal, at which point you call stop
At this point, I do not see the need for any use of native code from the
Java side.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Patrick Luby <pa...@sun.com> wrote:
> Pier,
>
> Pier Fumagalli wrote:
>>
>> IMO, it's a waste of time... You shouldn't call setuid from Java, but the
>> native code launching the VM should call appropriate methods at appropriate
>> moments of the lifecycle... As I said before:
>>
>> 1) CreateJavaVM
>> 2) call Tomcat->initialize() (bind to ports)
>> 3) set uid/euid/gid/egid/groups
>> 4) call Tomcat->start() (accept connections)
>> 5) wait for signal
>> 6) call Tomcat->stop()
>> 7) exit process...
>>
>> All the code is already in place... Just need to be tied together...
>
> I agree. I got your sample code to work on Mac OS X 10.1 and, just for kicks,
> had Java invoke the callback that was registered.
Save files, ./make.sh, ./testjni :)
> Since you have separated out the port binding into Tomcat->initialize(), you
> are
> also correct that I don't need to call the callback function from Java. I
> admit
> my thinking was still limited to the existing constraints of the
> StandardServer.start() method instead of the new bootstrap classes.
No, there should be a bootstrap already separating the entry points...
> Next thing I will do is take a look at the bootstrap classes and test out your
> recommendation.
Great :)
>> RegisterNative _is_ JNI... JNI is developed on two layers, call C from Java
>> (maybe using System.loadLibrary()), and that's what everyone knows.
>>
>> Call Java from C (a little bit less known, but way more powerful)...
>>
>> We need a JVM invocation API, not a Java callback mechanism, IMO...
>
> We used the JVM invocation API when I was working on StarOffice. However, I
> never ran into the RegisterNative method. Although we don't need it for the
> setuid() calls, I think it might come in handy sometime.
RegisterNatives is "gold", it's actually what it does at the end of
System.loadLibrary, going to analyze the exported functions from a DSO,
translating names, and calling it... See the JVM sources...
>> That's the beauty of JNI, you can do things that you won't even believe they
>> exist, like "compiling" (loading) a class when NOT all its methods are
>> there... It's the beauty of a Class seen as an Instance of an object (and
>> IMO the biggest advantage over things like SmallTalk)... JG thought it out
>> good...
>
> I admit that I kept expecting there to be more work to do. But you keep
> surprising me with what you have already implemented. Thanks for having the
> patience to walk me through this.
People were saying that I didn't do s*** while I was at Sun... I did
_something_, I just never had the chance to wrap it up (priorities were
changing from time to time)...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Pier,
Pier Fumagalli wrote:
>
> IMO, it's a waste of time... You shouldn't call setuid from Java, but the
> native code launching the VM should call appropriate methods at appropriate
> moments of the lifecycle... As I said before:
>
> 1) CreateJavaVM
> 2) call Tomcat->initialize() (bind to ports)
> 3) set uid/euid/gid/egid/groups
> 4) call Tomcat->start() (accept connections)
> 5) wait for signal
> 6) call Tomcat->stop()
> 7) exit process...
>
> All the code is already in place... Just need to be tied together...
I agree. I got your sample code to work on Mac OS X 10.1 and, just for kicks,
had Java invoke the callback that was registered.
Since you have separated out the port binding into Tomcat->initialize(), you are
also correct that I don't need to call the callback function from Java. I admit
my thinking was still limited to the existing constraints of the
StandardServer.start() method instead of the new bootstrap classes.
Next thing I will do is take a look at the bootstrap classes and test out your recommendation.
> RegisterNative _is_ JNI... JNI is developed on two layers, call C from Java
> (maybe using System.loadLibrary()), and that's what everyone knows.
>
> Call Java from C (a little bit less known, but way more powerful)...
>
> We need a JVM invocation API, not a Java callback mechanism, IMO...
We used the JVM invocation API when I was working on StarOffice. However, I
never ran into the RegisterNative method. Although we don't need it for the
setuid() calls, I think it might come in handy sometime.
> That's the beauty of JNI, you can do things that you won't even believe they
> exist, like "compiling" (loading) a class when NOT all its methods are
> there... It's the beauty of a Class seen as an Instance of an object (and
> IMO the biggest advantage over things like SmallTalk)... JG thought it out
> good...
>
I admit that I kept expecting there to be more work to do. But you keep
surprising me with what you have already implemented. Thanks for having the
patience to walk me through this.
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Remy Maucherat <re...@apache.org> wrote:
>> All the code is already in place... Just need to be tied together...
>
> Damn, wait a bit before posting, I was about to say the exact same thing ;-)
> Now I have to go back and edit my message :-P
Rounding up all mail before going to bed... Had enough of C code for the
day. :) Need to distract myself somehow :)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> Patrick Luby <pa...@sun.com> wrote:
>
> > Pier,
> >
> > I took a quick look at the code and found the RegisterNative function.
This
> > looks like an interesting feature. I also found the same function in
your
> > daemons code. The picture is becoming much clearer.
>
> Well, RegisterNative is there since at least 4 years... Kinda hard to do
> some callbacks without it....
>
> > Let me try to get it working in the next few days with the callback
function
> > set
> > to invoke setuid() and have the callback invoke (via Java reflection
since it
> > won't be there on Windows or standalone start.
>
> IMO, it's a waste of time... You shouldn't call setuid from Java, but the
> native code launching the VM should call appropriate methods at
appropriate
> moments of the lifecycle... As I said before:
>
> 1) CreateJavaVM
> 2) call Tomcat->initialize() (bind to ports)
> 3) set uid/euid/gid/egid/groups
> 4) call Tomcat->start() (accept connections)
> 5) wait for signal
> 6) call Tomcat->stop()
> 7) exit process...
>
> All the code is already in place... Just need to be tied together...
Damn, wait a bit before posting, I was about to say the exact same thing ;-)
Now I have to go back and edit my message :-P
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Patrick Luby <pa...@sun.com> wrote:
> Pier,
>
> I took a quick look at the code and found the RegisterNative function. This
> looks like an interesting feature. I also found the same function in your
> daemons code. The picture is becoming much clearer.
Well, RegisterNative is there since at least 4 years... Kinda hard to do
some callbacks without it....
> Let me try to get it working in the next few days with the callback function
> set
> to invoke setuid() and have the callback invoke (via Java reflection since it
> won't be there on Windows or standalone start.
IMO, it's a waste of time... You shouldn't call setuid from Java, but the
native code launching the VM should call appropriate methods at appropriate
moments of the lifecycle... As I said before:
1) CreateJavaVM
2) call Tomcat->initialize() (bind to ports)
3) set uid/euid/gid/egid/groups
4) call Tomcat->start() (accept connections)
5) wait for signal
6) call Tomcat->stop()
7) exit process...
All the code is already in place... Just need to be tied together...
> If I can get this to work, I will post the patches first so that all can
> inspect. Now that I understand this approach, it basically seems to work
> through
> the same logical steps (from a Tomcat Java code) perspective as invoking the
> callback function via JNI.
RegisterNative _is_ JNI... JNI is developed on two layers, call C from Java
(maybe using System.loadLibrary()), and that's what everyone knows.
Call Java from C (a little bit less known, but way more powerful)...
We need a JVM invocation API, not a Java callback mechanism, IMO...
> In your approach, the function is preloaded for Java (no System.loadLibrary()
> required) and the Java code invokes the function like any other method (it
> just happens that the method doesn't exist at compile time but only at
> runtime).
That's the beauty of JNI, you can do things that you won't even believe they
exist, like "compiling" (loading) a class when NOT all its methods are
there... It's the beauty of a Class seen as an Instance of an object (and
IMO the biggest advantage over things like SmallTalk)... JG thought it out
good...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Pier,
I took a quick look at the code and found the RegisterNative function. This
looks like an interesting feature. I also found the same function in your
daemons code. The picture is becoming much clearer.
Let me try to get it working in the next few days with the callback function set
to invoke setuid() and have the callback invoke (via Java reflection since it
won't be there on Windows or standalone start.
If I can get this to work, I will post the patches first so that all can
inspect. Now that I understand this approach, it basically seems to work through
the same logical steps (from a Tomcat Java code) perspective as invoking the
callback function via JNI.
In your approach, the function is preloaded for Java (no System.loadLibrary()
required) and the Java code invokes the function like any other method (it just
happens that the method doesn't exist at compile time but only at runtime).
Thanks,
Patrick
Pier Fumagalli wrote:
>
> Pier Fumagalli <pi...@betaversion.org> wrote:
>
> > Few hours...
>
> Yeah, whatever... Trivial...
>
> Pier
>
> --------------------------------------------------------------------------------
> Part 1.2Type: Macintosh File
>
> Part 1.3Type: Macintosh File
>
> Name: make.sh
> make.sh Type: Bourne Shell Program (application/x-sh)
> Encoding: base64
>
> Part 1.5Type: Plain Text (text/plain)
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Pier Fumagalli <pi...@betaversion.org> wrote:
> Few hours...
Yeah, whatever... Trivial...
Pier
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
Patrick Luby <pa...@sun.com> wrote:
> This is very true and was the reason I was pursuing the "public native" method
> approach. But Pier mentioned and passing a callback function to the JVM when
> he
> starts it. Maybe Pier could elaborate on this process? Basically, for Pier's
> callback approach to work, the callback function would need to be tied to
> invocation of the StandardServer.initialize() method. I haven't used any
> callbacks like he describes so I am curious about the mechanics.
Takes less time to come out with a proof of concept, maybe :) For MacOS/X...
Lately I've been faster at writing code than words...
Few hours...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
> >
> That wouldn't work - if the UID is changed before starting tomcat, then
> it can't listen on port 80.
>
> The uid must be changed after it start listening, like any unix program
> does. And the wrapper/invocator is just one way to start tomcat - I like
> the flexibility on startup.
>
This is very true and was the reason I was pursuing the "public native" method
approach. But Pier mentioned and passing a callback function to the JVM when he
starts it. Maybe Pier could elaborate on this process? Basically, for Pier's
callback approach to work, the callback function would need to be tied to
invocation of the StandardServer.initialize() method. I haven't used any
callbacks like he describes so I am curious about the mechanics.
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
costinm@covalent.net <co...@covalent.net> wrote:
> On Wed, 20 Feb 2002, Pier Fumagalli wrote:
>
>> 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()...
>
> That wouldn't work - if the UID is changed before starting tomcat, then
> it can't listen on port 80.
>
> The uid must be changed after it start listening, like any unix program
> does. And the wrapper/invocator is just one way to start tomcat - I like
> the flexibility on startup.
Look at the code... Port binding is done in initialize() in Tomcat 4.0
already.
>> 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 don't think Java means you shouldn't take advantage of the platform
> features. You can write platform independent code that is smart enough
> to detect the environment and use it, and provide fallback solutions.
I think that we have a way for doing it, so that is pushing the thing all
way around, having a different invocation API different from public static
void main(Strings []), which handles that case...
That's IMO a lot cleaner, but I'm not fighting about it as FWIW I don't
care. (Kinda fed up with all this fighting).
>>> - Add a "public static native" method in DaemonLoader.java
>
> The setuid class should be independent of DaemonLoader IMHO,
> people are using all kind of different 'deamon loaders' to
> start tomcat ( the sourceforge wrapper, javaService, etc ).
> Deamon is just one of them.
So, do you want a loader, or a setuid call? PUSH or POP? I'm starting to
loose the point of what you kids want to do at this point...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Wed, 20 Feb 2002, Pier Fumagalli wrote:
> 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()...
That wouldn't work - if the UID is changed before starting tomcat, then
it can't listen on port 80.
The uid must be changed after it start listening, like any unix program
does. And the wrapper/invocator is just one way to start tomcat - I like
the flexibility on startup.
> 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 don't think Java means you shouldn't take advantage of the platform
features. You can write platform independent code that is smart enough
to detect the environment and use it, and provide fallback solutions.
> > - Add a "public static native" method in DaemonLoader.java
The setuid class should be independent of DaemonLoader IMHO,
people are using all kind of different 'deamon loaders' to
start tomcat ( the sourceforge wrapper, javaService, etc ).
Deamon is just one of them.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Patrick Luby" <pa...@sun.com> 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!)...
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Pier,
Pier Fumagalli wrote:
>
> Patrick... System.loadlibrary (or however is called), does the exact
> opposite of what we need... We ship a binary that will load the JVM library,
> we don't rely on the JVM binary to load a library...
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
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 much sooner since my proposed approach is
compatible with the existing Tomcat configuration and startup.
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, 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?
Thanks,
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Patrick Luby" <pa...@sun.com> wrote:
> Pier,
>
> Pier Fumagalli wrote:
>>
>> "unique process"??? It's a DYLD "NSAddModule" call to the JVM library, and
>> CreateJavaVM is called CreateJavaVMImpl... Doesn't look that "unique"...
>
> It is unique if you want Java code to invoke a C function via JNI. On Mac OS
> X,
> you need to name the shared library *.jnilib instead of *.dylib if you want to
> invoke a "public native" Java method so that System.loadLibrary() will work.
> The
> use of NSAddModule works fine but is only accessible via C code with exists
> only
> in the parent process. Once you are with Tomcat (i.e. binding ports as root),
> you are limited to accessing C functions via System.loadLibrary() and invoking
> the "public native" Java method.
Patrick... System.loadlibrary (or however is called), does the exact
opposite of what we need... We ship a binary that will load the JVM library,
we don't rely on the JVM binary to load a library...
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...
The "Uniqueness" you're describing is just because of the fundamental
difference between "libraries" and "modules" on any Mach-O based operating
system: A "library" (DYLIB), is loaded in the scope of the whole process and
all its symbols table is merged indefinitely to the process, exactly as if a
binary linked against the same library was being launched (there's no
difference on symbols relocation on whether you "link" your binary to a
library, or you load it with NSAddModule after its invocation, in fact
that's all dyld does when spawning processes).
A "module" instead, can be loaded and unloaded at run time (more like a
"dso" does under ELF, or a "dll" in Windows)...
The main problem is that people tend to forget a basic intrinsic difference
between a DYLIB and a module (in words "MH_BUNDLE")... But wouldn't want to
go in deep on how the baby works (look at my recent post on patching Apache
2.0 behavior on Mach-O/DYLD based Oses).
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Pier,
Pier Fumagalli wrote:
>
> "unique process"??? It's a DYLD "NSAddModule" call to the JVM library, and
> CreateJavaVM is called CreateJavaVMImpl... Doesn't look that "unique"...
It is unique if you want Java code to invoke a C function via JNI. On Mac OS X,
you need to name the shared library *.jnilib instead of *.dylib if you want to
invoke a "public native" Java method so that System.loadLibrary() will work. The
use of NSAddModule works fine but is only accessible via C code with exists only
in the parent process. Once you are with Tomcat (i.e. binding ports as root),
you are limited to accessing C functions via System.loadLibrary() and invoking
the "public native" Java method.
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Patrick Luby" <pa...@sun.com> wrote:
> BTW, I have access to Linux, Solaris, and Mac OS X machines (the latter from
> my last job porting StarOffice to Mac OS X). So let me know where I can help
> out as I am intimately familiar with the unique process of getting JNI code to
> link on Mac OS X.
"unique process"??? It's a DYLD "NSAddModule" call to the JVM library, and
CreateJavaVM is called CreateJavaVMImpl... Doesn't look that "unique"...
Also, you might want to update your JVM installation, since
libappshell.dylib doesn't exist anymore in 1.3.1 on X...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
> If you have the time, writing this code as part of j-t-c/jk/native2/jni
> would be great :-) There are many things still missing there, like in-process
> support for 4.x and build procedure for other platforms ( we have
> ant-based support for libtool, win, netware - not sure if Mac supports
> libtool ).
>
Mac OS X has libtool, it is just the location of the JNI libraries at link time
and the need to create a shared library with a .jnilib extension (instead of a
.dylib extension like regular shared libraries :-( ). These should be fairly minor.
> It's better to write the native code using APR, it avoids all the ifdefs
> and system specific code, and it's tested already in apache.
>
I agree, I remember all of the special #ifdefs for the location of all of the
headers for Mac OS X.
>
> Costin
>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Patrick Luby wrote:
> I was thinking that since all ServerSocket binding is that we could implement
> this as a static native method so that both Tomcat 3.x and 4.x could load the
> shared library and invoke the calls as close as possible to the actual point
> that a ServerSocket object binds to the socket. In Tomcat 4.x, I believe that
> this point is in the createSocket() method of each ServerSocketFactory class.
>
> If you don't have time, let me know and I can try this later this week.
If you have the time, writing this code as part of j-t-c/jk/native2/jni
would be great :-) There are many things still missing there, like in-process
support for 4.x and build procedure for other platforms ( we have
ant-based support for libtool, win, netware - not sure if Mac supports
libtool ).
It's better to write the native code using APR, it avoids all the ifdefs
and system specific code, and it's tested already in apache.
Costin
> BTW, I have access to Linux, Solaris, and Mac OS X machines (the latter from my
> last job porting StarOffice to Mac OS X). So let me know where I can help out as
> I am intimately familiar with the unique process of getting JNI code to link on
> Mac OS X.
>
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Jean-Frederic,
jean-frederic clere wrote:
> That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native).
> Where is the chmod()?
> The idea of making setuid() and setgid() from the JVM is also possible - I will
> try it -
I was thinking that since all ServerSocket binding is that we could implement
this as a static native method so that both Tomcat 3.x and 4.x could load the
shared library and invoke the calls as close as possible to the actual point
that a ServerSocket object binds to the socket. In Tomcat 4.x, I believe that
this point is in the createSocket() method of each ServerSocketFactory class.
If you don't have time, let me know and I can try this later this week.
BTW, I have access to Linux, Solaris, and Mac OS X machines (the latter from my
last job porting StarOffice to Mac OS X). So let me know where I can help out as
I am intimately familiar with the unique process of getting JNI code to link on
Mac OS X.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Pier Fumagalli wrote:
>
> "jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
>
> > Remy Maucherat wrote:
> >>
> >>> "Patrick Luby" <pa...@sun.com> wrote:
> >>>
> >>>> Remy,
> >>>>
> >>>> This is great news!
> >>>>
> >>>> I scanned through the Unix code and noticed that it uses the chmod'ing
> >>>> executables with setuid bits instead of performing a JNI call to the
> >> setuid()
> >>>> and seteuid() C functions before and after binding of a ServerSocket
> >> (i.e. the
> >>>> place you should need root access if you are binding to ports 1 through
> >> 1024).
> >>>> This type of approach eliminates the need for a controller and slave
> >> process.
> >>>
> >>> Then it's not my code... My code was written using setuid() and
> >> seteuid()...
> >>> Actually, the copy I have here also supports CHROOTING of the whole JVM
> >>> process, and real/effective group switching (as we say in Italy, "'na
> >> botte
> >>> de fero").
> >>
> >> There weren't 10 different copies of that code. Just one in j-t-s ;-)
> >> Obviously, I couldn't have written it myself.
> >
> > That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native).
> > Where is the chmod()?
> > The idea of making setuid() and setgid() from the JVM is also possible - I
> > will
> > try it -
>
> There are way-too-many copies in way-too-many places (three found so far on
> CVS... Shaitz!)... Bah, my fault!!$!^@$(U#!@$%*(@&#$%!)*&%!
Creative Chaos!
>
> Pier
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
> Remy Maucherat wrote:
>>
>>> "Patrick Luby" <pa...@sun.com> wrote:
>>>
>>>> Remy,
>>>>
>>>> This is great news!
>>>>
>>>> I scanned through the Unix code and noticed that it uses the chmod'ing
>>>> executables with setuid bits instead of performing a JNI call to the
>> setuid()
>>>> and seteuid() C functions before and after binding of a ServerSocket
>> (i.e. the
>>>> place you should need root access if you are binding to ports 1 through
>> 1024).
>>>> This type of approach eliminates the need for a controller and slave
>> process.
>>>
>>> Then it's not my code... My code was written using setuid() and
>> seteuid()...
>>> Actually, the copy I have here also supports CHROOTING of the whole JVM
>>> process, and real/effective group switching (as we say in Italy, "'na
>> botte
>>> de fero").
>>
>> There weren't 10 different copies of that code. Just one in j-t-s ;-)
>> Obviously, I couldn't have written it myself.
>
> That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native).
> Where is the chmod()?
> The idea of making setuid() and setgid() from the JVM is also possible - I
> will
> try it -
There are way-too-many copies in way-too-many places (three found so far on
CVS... Shaitz!)... Bah, my fault!!$!^@$(U#!@$%*(@&#$%!)*&%!
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
>
> > "Patrick Luby" <pa...@sun.com> wrote:
> >
> > > Remy,
> > >
> > > This is great news!
> > >
> > > I scanned through the Unix code and noticed that it uses the chmod'ing
> > > executables with setuid bits instead of performing a JNI call to the
> setuid()
> > > and seteuid() C functions before and after binding of a ServerSocket
> (i.e. the
> > > place you should need root access if you are binding to ports 1 through
> 1024).
> > > This type of approach eliminates the need for a controller and slave
> process.
> >
> > Then it's not my code... My code was written using setuid() and
> seteuid()...
> > Actually, the copy I have here also supports CHROOTING of the whole JVM
> > process, and real/effective group switching (as we say in Italy, "'na
> botte
> > de fero").
>
> There weren't 10 different copies of that code. Just one in j-t-s ;-)
> Obviously, I couldn't have written it myself.
That Pier's code (in jakarta-commons-sandbox/daemon/src/native/unix/native).
Where is the chmod()?
The idea of making setuid() and setgid() from the JVM is also possible - I will
try it -
>
> Anyway, improvements are always welcome :)
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> "Patrick Luby" <pa...@sun.com> wrote:
>
> > Remy,
> >
> > This is great news!
> >
> > I scanned through the Unix code and noticed that it uses the chmod'ing
> > executables with setuid bits instead of performing a JNI call to the
setuid()
> > and seteuid() C functions before and after binding of a ServerSocket
(i.e. the
> > place you should need root access if you are binding to ports 1 through
1024).
> > This type of approach eliminates the need for a controller and slave
process.
>
> Then it's not my code... My code was written using setuid() and
seteuid()...
> Actually, the copy I have here also supports CHROOTING of the whole JVM
> process, and real/effective group switching (as we say in Italy, "'na
botte
> de fero").
There weren't 10 different copies of that code. Just one in j-t-s ;-)
Obviously, I couldn't have written it myself.
Anyway, improvements are always welcome :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, jean-frederic clere wrote:
> Costin has started something like that in
> jakarta-tomcat-connectors/jk/native/jni/jk_jni_aprImpl.c the way is the good
> one: Use APR to save porting problems.
Yes, jk2 will make use of apr.
One 'piece' of jk is a JNI library that will be used from java to
access APR functions - userid is trivial, also shmem, signals, etc.
The main benefit of Apr is that it already have all the
OS specific things factored out.
It would be very nice if we would keep all JNI code in jk:
- more people are working on it
- the build system is there ( not perfect, but it'll improve )
- people need to build jk anyway.
We can split it in 2 ( APR-java and jk ), but for now I think
it would be much easier to keep things in sync until they
mature.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Patrick Luby wrote:
>
> Pier,
>
> Hmmm. I could only find the setuid() calls in the parent process that launches
> Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat could
> use to temporarily switch the user back to root immediately before binding a
> ServerSocket object and then switching the user back immediately after. Maybe
> that code already exists somewhere else? If so, let me know where it is and I
> will definitely use it.
Costin has started something like that in
jakarta-tomcat-connectors/jk/native/jni/jk_jni_aprImpl.c the way is the good
one: Use APR to save porting problems.
>
> BTW, I like the native startup executable that you wrote. I made a proposal to
> this list last week about replacing our many shell scripts (which are causing
> alot of nasty problems on Windows) with a launcher that uses properties files to
> launch Tomcat or the other related tools. I had originally thought about having
> a Java read the properties which would then launch Tomcat. However, you native
> code, especialy with its support for signals and chrooting may be a better
> option. Sure, I would need the native code to read some properties files to get
> classpath and other configurable items, but then I could directly invoke Java to
> run the Tomcat classes.
>
> Thanks,
>
> Patrick
>
> Pier Fumagalli wrote:
> >
> > "Patrick Luby" <pa...@sun.com> wrote:
> >
> > > Remy,
> > >
> > > This is great news!
> > >
> > > I scanned through the Unix code and noticed that it uses the chmod'ing
> > > executables with setuid bits instead of performing a JNI call to the setuid()
> > > and seteuid() C functions before and after binding of a ServerSocket (i.e. the
> > > place you should need root access if you are binding to ports 1 through 1024).
> > > This type of approach eliminates the need for a controller and slave process.
> >
> > Then it's not my code... My code was written using setuid() and seteuid()...
> > Actually, the copy I have here also supports CHROOTING of the whole JVM
> > process, and real/effective group switching (as we say in Italy, "'na botte
> > de fero").
> >
> > Pier
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> _____________________________________________________________________
> Patrick Luby Email: patrick.luby@sun.com
> Sun Microsystems Phone: 408-276-7471
> 901 San Antonio Road, USCA14-303
> Palo Alto, CA 94303-4900
> _____________________________________________________________________
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> Remy,
>
> Remy Maucherat wrote:
> > jsvc and the Daemon code don't use the normal Bootstrap class, but
rather
> > use BootstrapService, which is the one which implements the
Service/Daemon
> > interface. This shouldn't call StandardServer.await, but rather will
only
> > call the start and stop method.
> >
> > So doing the setuid change during the daemon init method should work,
since
> > that's where the connectors are initialized.
> >
> > Or did I get something wrong ?
>
> await() is invoked in the Catalina.start() method. So, if you start
standalone (as Unix /etc/rc.d scripts do), Tomcat will invoke
Catalina.start().
But BootstrapService uses CatalinaService, which doesn't do that.
I agree that the standard classes are not suitable to be run as a daemon,
but they've never been designed for that (I have written BootstrapService
and CatalinaService in collaboration with Pier specially for this purpose).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Remy,
Remy Maucherat wrote:
> jsvc and the Daemon code don't use the normal Bootstrap class, but rather
> use BootstrapService, which is the one which implements the Service/Daemon
> interface. This shouldn't call StandardServer.await, but rather will only
> call the start and stop method.
>
> So doing the setuid change during the daemon init method should work, since
> that's where the connectors are initialized.
>
> Or did I get something wrong ?
await() is invoked in the Catalina.start() method. So, if you start standalone (as Unix /etc/rc.d scripts do), Tomcat will invoke Catalina.start().
Patrick
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Remy Maucherat <re...@apache.org>.
> Costin,
>
> costinm@covalent.net wrote:
> >
> > That would be after all connectors have opened the ports, but before
_any_
> > user code gets executed ( including the context init which trigers
loading
> > of on-startup servlets ).
>
> In Tomcat 4.x, the last port opened is in StandardServer.await() - this is
the
> shutdown port. The bad news is that all of the connectors are started
before
> this call. Hence, I suspect that there is, currently, a small window for
user
> code to get executed before the setuid would be called in
StandardServer.await().
>
> Looks like the Tomcat 4.x code in Catalina.start() will need to be
reworked.
> However, after a quick review of the code, I don't think it is that much
work.
> All of the connectors bind to their ports in their initialize() method and
no
> user code, AFAIK, is executed in this method. After all connectors are
> intialized(), only then are the connectors started. So, I am thinking that
all I
> need to do is move the shutdown port binding out of StandardServer.await()
and
> into StandardServer.initialize(). Since StandardServer.initialize()
invokes
> initialize() on all of the connectors, I can put the setuid code at the
end of
> the StandardServer.initialize() method.
>
> Of course, this is how I think it will work so I definitely need to try it
out.
> Maybe later this week I will have some time to try this out and make sure
that
> it actually works.
jsvc and the Daemon code don't use the normal Bootstrap class, but rather
use BootstrapService, which is the one which implements the Service/Daemon
interface. This shouldn't call StandardServer.await, but rather will only
call the start and stop method.
So doing the setuid change during the daemon init method should work, since
that's where the connectors are initialized.
Or did I get something wrong ?
BTW, let me know if you're interested in contributing to Daemon. I can add
your name to the proposal in the commons. Same goes for Costin, Henri, etc,
etc. The more people contributing to the component, the faster it will get
out of the sandbox :)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
>
> That would be after all connectors have opened the ports, but before _any_
> user code gets executed ( including the context init which trigers loading
> of on-startup servlets ).
In Tomcat 4.x, the last port opened is in StandardServer.await() - this is the
shutdown port. The bad news is that all of the connectors are started before
this call. Hence, I suspect that there is, currently, a small window for user
code to get executed before the setuid would be called in StandardServer.await().
Looks like the Tomcat 4.x code in Catalina.start() will need to be reworked.
However, after a quick review of the code, I don't think it is that much work.
All of the connectors bind to their ports in their initialize() method and no
user code, AFAIK, is executed in this method. After all connectors are
intialized(), only then are the connectors started. So, I am thinking that all I
need to do is move the shutdown port binding out of StandardServer.await() and
into StandardServer.initialize(). Since StandardServer.initialize() invokes
initialize() on all of the connectors, I can put the setuid code at the end of
the StandardServer.initialize() method.
Of course, this is how I think it will work so I definitely need to try it out.
Maybe later this week I will have some time to try this out and make sure that
it actually works.
Thanks,
Patrick
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> On Tue, 19 Feb 2002, Patrick Luby wrote:
>
>> focus my efforts on finding a good place in Tomcat 4.x to setuid to a
>> non-root
>> user like Apache does instead of pursuing this probably platform specific use
>> of setuid.
>
> That would be after all connectors have opened the ports, but before _any_
> user code gets executed ( including the context init which trigers loading
> of on-startup servlets ).
org.apache.catalina.Connector.initialize()...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Patrick Luby wrote:
> focus my efforts on finding a good place in Tomcat 4.x to setuid to a non-root
> user like Apache does instead of pursuing this probably platform specific use of setuid.
That would be after all connectors have opened the ports, but before _any_
user code gets executed ( including the context init which trigers loading
of on-startup servlets ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
>
> On Tue, 19 Feb 2002, Patrick Luby wrote:
>
> My point was that after you drop the root priviledges, there's no way
> to get them back.
>
> I just double checked the manual, at least on linux.
Hmmm. I picked this up from the Solaris man pages. It is probably best for me to
focus my efforts on finding a good place in Tomcat 4.x to setuid to a non-root
user like Apache does instead of pursuing this probably platform specific use of setuid.
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Patrick Luby wrote:
> > Changing the uid to root is certainly impossible AFAIK ( at least on
> > unix, on NT everything is possible, but I hope not this one ).
> >
> Well, of course the process would have to be started as root and the setuid to a
> non-root user happens at the start of the process. Then, the JNI calls allow you
> to invoke setuid to switch back to the "saved uid" which is root (since that is
> the uid of the parent process). The only issue that think that may be
> problematic is multi-threading since all threads get switched back to root momemtarily.
My point was that after you drop the root priviledges, there's no way
to get them back.
I just double checked the manual, at least on linux.
Apache and all other unix daemons are started as root, they aquire the
port, then drop priviledges.
If calling setuid() again would get back to root, what would be the point?
The hacker exploiting a stack overflow could easily call setuid.
> My only worry here is how much resistance there would be for native executables
> to launch Tomcat and/or other tools. Of course, one could also launch Java
> directly so maybe this will make this idea more palatable.
JK and inprocess already require jni.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Costin,
costinm@covalent.net wrote:
>
> How easy would it be if that was possible ? For both hackers and
> developers :-)
If we keep this as a "public static void" method, these could be used by any
codebase (as long as they pulled in the .jar and shared library files).
>
> Changing the uid to root is certainly impossible AFAIK ( at least on
> unix, on NT everything is possible, but I hope not this one ).
>
Well, of course the process would have to be started as root and the setuid to a
non-root user happens at the start of the process. Then, the JNI calls allow you
to invoke setuid to switch back to the "saved uid" which is root (since that is
the uid of the parent process). The only issue that think that may be
problematic is multi-threading since all threads get switched back to root momemtarily.
The reason I am proposing this tricky approach is that, at least in Tomcat 4.x,
the ServerSocket binding is not all in one place in the code or, AFAIK, right at
the beginning of main(). Hence, it looks like it will be impractical to do all
of the socket binding and then setuid to the non-root user without moving a lot
of code around. I will continue to look at this, however, because of the
threading issue .
> The other part is possible and I think it's a very good solution.
My only worry here is how much resistance there would be for native executables
to launch Tomcat and/or other tools. Of course, one could also launch Java
directly so maybe this will make this idea more palatable.
>
> Costin
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> How easy would it be if that was possible ? For both hackers and
> developers :-)
Well, if you set your binary in chmod u+S your process is started as root
(big NONO)... I don't quite get what Patrick want to do, but having a suid
binary doesn't make it to my hard disk...
> Changing the uid to root is certainly impossible AFAIK ( at least on
> unix, on NT everything is possible, but I hope not this one ).
Possible :(
> The other part is possible and I think it's a very good solution.
Root->User? Yeah. We just need to have a 2 stage initialization process
(that's why several months ago I added a method in Catalina's "connector"
interface called "initialize" (check out the JavaDOCs! :)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Patrick Luby wrote:
> Pier,
>
> Hmmm. I could only find the setuid() calls in the parent process that launches
> Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat could
> use to temporarily switch the user back to root immediately before binding a
> ServerSocket object and then switching the user back immediately after. Maybe
How easy would it be if that was possible ? For both hackers and
developers :-)
Changing the uid to root is certainly impossible AFAIK ( at least on
unix, on NT everything is possible, but I hope not this one ).
The other part is possible and I think it's a very good solution.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Patrick Luby" <pa...@sun.com> wrote:
> Pier,
>
> Hmmm. I could only find the setuid() calls in the parent process that launches
> Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat
> could use to temporarily switch the user back to root immediately before
> binding a ServerSocket object and then switching the user back immediately
> after. Maybe that code already exists somewhere else? If so, let me know where
> it is and I will definitely use it.
Hmm... I just checked the copy on CVS (jakarta-tomcat-4.0/service) and it's
how you describe it... Weirrddddd, can't remember... Let me check around @
home to see on my backups...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Pier,
Hmmm. I could only find the setuid() calls in the parent process that launches
Tomcat. I couln't find any code JNI code (or a shared library) that Tomcat could
use to temporarily switch the user back to root immediately before binding a
ServerSocket object and then switching the user back immediately after. Maybe
that code already exists somewhere else? If so, let me know where it is and I
will definitely use it.
BTW, I like the native startup executable that you wrote. I made a proposal to
this list last week about replacing our many shell scripts (which are causing
alot of nasty problems on Windows) with a launcher that uses properties files to
launch Tomcat or the other related tools. I had originally thought about having
a Java read the properties which would then launch Tomcat. However, you native
code, especialy with its support for signals and chrooting may be a better
option. Sure, I would need the native code to read some properties files to get
classpath and other configurable items, but then I could directly invoke Java to
run the Tomcat classes.
Thanks,
Patrick
Pier Fumagalli wrote:
>
> "Patrick Luby" <pa...@sun.com> wrote:
>
> > Remy,
> >
> > This is great news!
> >
> > I scanned through the Unix code and noticed that it uses the chmod'ing
> > executables with setuid bits instead of performing a JNI call to the setuid()
> > and seteuid() C functions before and after binding of a ServerSocket (i.e. the
> > place you should need root access if you are binding to ports 1 through 1024).
> > This type of approach eliminates the need for a controller and slave process.
>
> Then it's not my code... My code was written using setuid() and seteuid()...
> Actually, the copy I have here also supports CHROOTING of the whole JVM
> process, and real/effective group switching (as we say in Italy, "'na botte
> de fero").
>
> Pier
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Patrick Luby" <pa...@sun.com> wrote:
> Remy,
>
> This is great news!
>
> I scanned through the Unix code and noticed that it uses the chmod'ing
> executables with setuid bits instead of performing a JNI call to the setuid()
> and seteuid() C functions before and after binding of a ServerSocket (i.e. the
> place you should need root access if you are binding to ports 1 through 1024).
> This type of approach eliminates the need for a controller and slave process.
Then it's not my code... My code was written using setuid() and seteuid()...
Actually, the copy I have here also supports CHROOTING of the whole JVM
process, and real/effective group switching (as we say in Italy, "'na botte
de fero").
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Daemon] New commons component
Posted by Patrick Luby <pa...@sun.com>.
Remy,
This is great news!
I scanned through the Unix code and noticed that it uses the chmod'ing
executables with setuid bits instead of performing a JNI call to the setuid()
and seteuid() C functions before and after binding of a ServerSocket (i.e. the
place you should need root access if you are binding to ports 1 through 1024).
This type of approach eliminates the need for a controller and slave process.
If there is interest out there, I can work up a proposal for implementing this
type of setuid functionality. I has been a year or two since I did my last JNI
coding, but I should be able to dig up some setuid code that I have done in the past.
Thanks,
Patrick
Remy Maucherat wrote:
>
> Hi,
>
> I've added a new component to the commons subproject (in the sandbox), which
> is designed to allow Java programs to run as native operating system daemons
> (services under Windows NT).
> Because of its nature, this component contains a significant amount of
> native code.
>
> This component API and Unix code was developed by Pier Fumagalli as part of
> the Tomcat 4 project, but is fully generic and not tied in any way to
> Tomcat, so other server side applications may find it useful.
>
> The NT service code and related utilities were written by Jean-Frederic
> Clere.
>
> Thanks,
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>