after opening up all permissions for the web-app following your advice we finally found the reason in a bug in the ypbind of the machine running tomcat: so my guess, that spawned processes are restricted in any way were obviously wrong - especially there does not seem to be a way of restricting spawned processes. Either you are granted permission to exec or not, but nothing in between (this is fine by me, we are just happy to have our exec's run smooth again...)
thx for the help
stf
Patrick Willart wrote:
Stefan,
The security manager is disabled per default. In your specific case it has nothing to do with the security manager either. The problem is that the program/script you started with runtime.exec() doesn't have permission to open a socket. The security manager, if enabled, could control the permission to use .exec() and .exit() methods in your java code. Not in external scripts/programs you execute.
As I told you, I worked around this by rewriting the program in as a servlet. I never got the original CGI program to open a socket. I think external programs launched by Tomcat always have this restriction. Maybe one of developers can confirm this behavior?
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/security-manager-howto.html
grts,
Patrick
-----Original Message----- From: Kwok Peng Tuck [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 12:26 AM To: Tomcat Users List Subject: Re: Strange behavior of runtime.exec(...)
If I'm not mistaken, the security manager is turned off by default.
Stefan Frank wrote:
I tried to tweak the security manager of tomcat(using no restrictions at all) - with no effect. And I have absolutely no idea how to set the security-settings for the Webapp: And if i knew, does anyone know if there is a level of control below the reight to call runtime.exec()?! I mean, if the webapp is allowed to spawn a process, can i restrict the abilities of this spawned process?! And in a platform independent matter?! Or is there a bug somwehere else?! Patrick Willart wrote:
I suspect the problem to be that no external task that is started by Tomcat is allowed to open any connections.
I had a similar problem with cgi and a windows executable. The executable tried to open a socket connection. The same setup had worked on a different server but not on Tomcat. I ended up rewritting the program as a java servlet. This worked.
If you setup a Security Manager for Tomcat then you can control what the java code of your applications is allowed to do.
Grts,
Patrick -----Original Message----- From: Stefan Frank [mailto:[EMAIL PROTECTED] Sent: Saturday, November 08, 2003 6:52 AM To: [EMAIL PROTECTED] Subject: Strange behaviour of runtime.exec(...)
Hi,
we are trying to make some calls to scripts from within tomcat, so we are using runtime.exec() inside a Servlet: The script (it submits a Job to teh Sun Grid Engine, http://gridengine.sunsource.net/) runs fine from the command line, and also the java-class, which is called from the servlet for the submit, runs fine outside of tomcat: When the Class is called from inside tomcat, the job is submitted, but never reaches the scheduler: It looks like the spawned process is not allowed to make up sockets to the outside world - are there any restrictions on using Runtime.exec() from within tomcat?! And if there is, is there a way around these restrictions?!
Greetings&thx in advance for any help Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
