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 w
[EMAIL PROTECTED] <[EMAIL PROTECTED]> 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()-lik
> 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
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
> 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 t
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, m
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
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
--
_
> 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 :)
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
> 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 s
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 conta
Patrick Luby <[EMAIL PROTECTED]> 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) Cre
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
> 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, th
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 th
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 por
Remy Maucherat <[EMAIL PROTECTED]> 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
Remy Maucherat <[EMAIL PROTECTED]> 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 enou
> 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
> Patrick Luby <[EMAIL PROTECTED]> 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 i
Patrick Luby <[EMAIL PROTECTED]> 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 a
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 invo
Patrick Luby <[EMAIL PROTECTED]> 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 se
Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> Few hours...
Yeah, whatever... Trivial...
Pier
test.c
Description: application/applefile
test.c
Description: Binary data
Test.java
Description: application/applefile
Test.java
Description: Binary data
make.sh
Description: Binary data
Patrick Luby <[EMAIL PROTECTED]> 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 ap
Patrick Luby <[EMAIL PROTECTED]> 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() s
[EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
Remy Maucherat <[EMAIL PROTECTED]> 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
Costin,
[EMAIL PROTECTED] 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
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 "publ
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 n
Costin,
[EMAIL PROTECTED] 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
> t
> 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 (whi
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 sy
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
> per
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
> "Patrick Luby" <[EMAIL PROTECTED]> wrote:
>
> > Maybe I should clarify what I am trying to do. I am trying to enable the
use
> > of setuid() within the existing Tomcat startup process (i.e. shell
scripts). I
> > definitely like your native launcher and the more I look at it, the more
I
> > like
Comments below...
Pier Fumagalli wrote:
>
> "Patrick Luby" <[EMAIL PROTECTED]> wrote:
>
> > Maybe I should clarify what I am trying to do. I am trying to enable the use
> > of setuid() within the existing Tomcat startup process (i.e. shell scripts). I
> > definitely like your native launcher an
"Patrick Luby" <[EMAIL PROTECTED]> wrote:
> Maybe I should clarify what I am trying to do. I am trying to enable the use
> of setuid() within the existing Tomcat startup process (i.e. shell scripts). I
> definitely like your native launcher and the more I look at it, the more I
> like its sophist
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 t
"Patrick Luby" <[EMAIL PROTECTED]> 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
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 libra
Pier Fumagalli wrote:
>
> "jean-frederic clere" <[EMAIL PROTECTED]> wrote:
>
> > Remy Maucherat wrote:
> >>
> >>> "Patrick Luby" <[EMAIL PROTECTED]> wrote:
> >>>
> Remy,
>
> This is great news!
>
> I scanned through the Unix code and noticed that it uses the chmod'ing
>
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 m
"Patrick Luby" <[EMAIL PROTECTED]> 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
"jean-frederic clere" <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
>>
>>> "Patrick Luby" <[EMAIL PROTECTED]> 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
"Patrick Luby" <[EMAIL PROTECTED]> 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
> 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 m
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.
>
> S
> Costin,
>
> [EMAIL PROTECTED] 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(
It's very easy at least in Unix world to have tomcat
run as a basic user :
Attached is the wrapper code (tomcat4) I use in TC 4.0.2 RPMS
which replace catalina.sh
dtomcat4 is a modified version of catalina.sh
Ditto for jasper4 and djasper4
I'm unsure it's very usefull to have Tomcat 4.0 start
Costin,
[EMAIL PROTECTED] 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
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
Costin,
[EMAIL PROTECTED] 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 probabl
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 t
Henri,
There should be no requirement for Tomcat to start as root. However, some may
want to run Tomcat on a port < 1024. In such cases, you need to start as root
but most site admins want the process to setuid to a non-root user for security
reasons.
Patrick
GOMEZ Henri wrote:
>
> >Well, of
>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
Costin,
[EMAIL PROTECTED] 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, net
Costin,
[EMAIL PROTECTED] 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 r
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 ServerSo
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
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
>
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
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
Remy Maucherat wrote:
>
> > "Patrick Luby" <[EMAIL PROTECTED]> 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
> I saw there is provisions in commons-sandbox daemon for
> Interception of Signals.
> Did there is plan to add this feature to Tomcat 3.3.1/4.0.2
> as it will be a real bonus for site admins ?
Well, the BootstrapService class is implementing the service/daemon API, so
if you use it instead of B
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 i
> "Patrick Luby" <[EMAIL PROTECTED]> 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 bindin
"Patrick Luby" <[EMAIL PROTECTED]> 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 ServerSo
I saw there is provisions in commons-sandbox daemon for
Interception of Signals.
Did there is plan to add this feature to Tomcat 3.3.1/4.0.2
as it will be a real bonus for site admins ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY :
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
> pla
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 a
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 Un
75 matches
Mail list logo
