You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christian Stalp <st...@imbei.uni-mainz.de> on 2005/06/13 16:01:57 UTC
starting a binary by calling a servlet
Hello out there,
I want to start a process, a program by calling a servlet.
The servlet itself is creating a runtime on its vm.
It looks something like this:
[code]
String cmd1 = "/usr/bin/myproc";
Runtime rt = Runtime.getRuntime();
Process myproc = rt.exec( cmd1 );
rueck_gabe = myproc.waitFor();
[/code]
But at the Moment I get an error that this is not allowed for a Servlet which
seems logical to me. So I have to change the catalina.policy.
The question is now: how?
What I have to do, to enable my servlet to start binarys on my host?
Can anybody help me?
Thank you very much!
Gruss Christian
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Markus Schönhaber <ma...@schoenhaber.de>.
Am Freitag, 17. Juni 2005 14:56 schrieb Christian Stalp:
Please don't CC me. I'm reading the list and have set the Reply-To for a
reason. Thanks.
> Im now back again. Now I have time to fix the tomcat-problem. But first I
> have another problem: I cannot start tomcat!!!
>
> I got this from my latest logfile: catalina_2005-06-17.log
> This is of course only a small part of it. Is this caused by a mistaken
> entry in the catalina.policy?
>
> [quote]
> Using Security Manager
> Created MBeanServer with ID: 4aa0ce:10489ba2bdb:-8000:gandalf:1
> Jun 17, 2005 11:56:17 AM org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8180
> Jun 17, 2005 11:56:17 AM org.apache.commons.digester.Digester fatalError
> SEVERE: Parse Fatal Error at line 1 column 1: Content is not allowed in
> prolog.
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at org.apache.xerces.u.....
> [/quote]
I doubt this has anything to do with catalina.policy. This seems to be an
error thrown by the XML parser - but catalina.polica is plain-text file.
Check the XML config files and context descriptors. Maybe there's something
wrong with them - for example byte order marks at the beginning of the file
(i. e. before the "<?xml version..." line).
>
> But the weired thing is, my own entry into the catalina.policy is gone, is
> erased!!! And this happens everytime I reboot my system.
> Each time I edit the cataline.policy I cannot restart tomcat again. So I
> choose the windows(tm) solution and reboot the whole system! But when the
> system is up and running again. Tomcat cannot start at all. AND my entry in
> the catalina.policy is ....gone!!!!
Can't help you with that. Your system seems to behave a bit - hm - strange. I
doubt that tomcat is removing entries from catalina.policy.
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Christian Stalp <st...@imbei.uni-mainz.de>.
> Excuse me for a moment. Now I have the trouble that I cannot restart Tomcat
> and so I had to reboot the whole system. Now tomcat start while the
> bootprocess but cannot be accessed over the browser. And I don't have a
> process called catalina nor tomcat !?!?!
>
> Gruss Christian
Im now back again. Now I have time to fix the tomcat-problem. But first I have
another problem: I cannot start tomcat!!!
I got this from my latest logfile: catalina_2005-06-17.log
This is of course only a small part of it. Is this caused by a mistaken entry
in the catalina.policy?
[quote]
Using Security Manager
Created MBeanServer with ID: 4aa0ce:10489ba2bdb:-8000:gandalf:1
Jun 17, 2005 11:56:17 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8180
Jun 17, 2005 11:56:17 AM org.apache.commons.digester.Digester fatalError
SEVERE: Parse Fatal Error at line 1 column 1: Content is not allowed in
prolog.
org.xml.sax.SAXParseException: Content is not allowed in prolog.
at org.apache.xerces.u.....
[/quote]
But the weired thing is, my own entry into the catalina.policy is gone, is
erased!!! And this happens everytime I reboot my system.
Each time I edit the cataline.policy I cannot restart tomcat again. So I
choose the windows(tm) solution and reboot the whole system! But when the
system is up and running again. Tomcat cannot start at all. AND my entry in
the catalina.policy is ....gone!!!!
Gruss Christian
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Tim Diggins <su...@red56.co.uk>.
And I presume you'd need to get/persist this java object to a database,
if you fancied scaling beyond a single application server? (Or am I
missing something?)
Andre Van Klaveren wrote:
> This will prevent users from having more than one session at a time
> for sure. You would probably want to remove the id from the list when
> a duplicate is detected to prevent users from having to wait for their
> initial session to timeout in the event that they closed their browser
> without properly logging out. You would also need to keep the session
> id in this list so that you can invalidate the session that is related
> to the id.
>
> This of course would drop the original session and in the event that
> two people were using the same ID it would become a nuisence for the
> first user to login (they would loose their session).
>
> You would want to make sure to log this event for auditing purpose as well.
>
> Did I miss anything?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Andre Van Klaveren <ny...@gmail.com>.
This will prevent users from having more than one session at a time
for sure. You would probably want to remove the id from the list when
a duplicate is detected to prevent users from having to wait for their
initial session to timeout in the event that they closed their browser
without properly logging out. You would also need to keep the session
id in this list so that you can invalidate the session that is related
to the id.
This of course would drop the original session and in the event that
two people were using the same ID it would become a nuisence for the
first user to login (they would loose their session).
You would want to make sure to log this event for auditing purpose as well.
Did I miss anything?
--
Virtually,
Andre Van Klaveren
Architect III, SCP
Enterprise Transformation Services
Unisys Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Woodchuck <wo...@yahoo.com>.
yes, this boils down to a business policy issue. in my web app the
policy is 'one user at any one time'. we track user logins at the
database level. we immediately invalidate the existing user session if
the same user has just logged in (again).
the existing user gets a "your session has expired" message upon their
next action in the web app. basically, the latest login wins.
this is the behavior/policy our client is happy with.
woodchuck
--- Andre Van Klaveren <ny...@gmail.com> wrote:
> I mentioned this issue (killing browser problem) in a previous
> posting. The only way to prevent this is to invalidate the original
> session also in the event that a duplicate login was detected. I can
> see a possible DOS attack problem with this solution though. Maybe
> you shouldn't invalidate the original session and make the user call
> helpdesk to invalidate the original session. This would aid in the
> tracking of this event also.
>
> Using IP addresses is usually not a good way to detect duplicate
> logins. I guess this would work in a controlled environment
> (intranet) where you can guarantee that the user(s) aren't behind a
> proxy server. It's definetly not an option for a public site.
>
>
>
> On 6/15/05, Nikola Milutinovic <Ni...@ev.co.yu> wrote:
> > David Rickard wrote:
> >
> > > Don't know if this is an optimum solution, but it should work:
> > > Keep a List or Vector of IDs for active users in a shared,
> > > application-level object (probably ServletContext);
> > > When someone logs in, search the List for the submitted ID: if
> not
> > > present, continue with login sequence; if present, kick them to
> the
> > > "duplicate login" page;
> > > Remove IDs from the List when users log out (and add a
> > > ServletContextListener to catch people who leave the site without
> > > logging out--remove their IDs when their sessions time out);
> >
> >
> > This is definitely a correct approach, but it has onw shortcoming.
> > Suppose one user opens up a session (logs in) and his/her browser
> dies.
> > The user opens another browser and tries to login, only to be
> kicked to
> > "duplicate user" page. I think in this case, the original poster
> should
> > have a vector or a hash map of user names and remote machine
> names/IPs.
> >
> > Nix.
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Virtually,
> Andre Van Klaveren
> Architect III, SCP
> Enterprise Transformation Services
> Unisys Corporation
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
Andre Van Klaveren wrote:
>I mentioned this issue (killing browser problem) in a previous
>posting. The only way to prevent this is to invalidate the original
>session also in the event that a duplicate login was detected. I can
>see a possible DOS attack problem with this solution though. Maybe
>you shouldn't invalidate the original session and make the user call
>helpdesk to invalidate the original session. This would aid in the
>tracking of this event also.
>
>
To DoS or not to DoS? I would let the session expire naturally, let the
SessionListener cleanup and logout the user and when a duplicate comes
in tell them what is the case. If they need access *now*, they can call
the help desk.
>Using IP addresses is usually not a good way to detect duplicate
>logins. I guess this would work in a controlled environment
>(intranet) where you can guarantee that the user(s) aren't behind a
>proxy server. It's definetly not an option for a public site.
>
>
True.
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Andre Van Klaveren <ny...@gmail.com>.
I mentioned this issue (killing browser problem) in a previous
posting. The only way to prevent this is to invalidate the original
session also in the event that a duplicate login was detected. I can
see a possible DOS attack problem with this solution though. Maybe
you shouldn't invalidate the original session and make the user call
helpdesk to invalidate the original session. This would aid in the
tracking of this event also.
Using IP addresses is usually not a good way to detect duplicate
logins. I guess this would work in a controlled environment
(intranet) where you can guarantee that the user(s) aren't behind a
proxy server. It's definetly not an option for a public site.
On 6/15/05, Nikola Milutinovic <Ni...@ev.co.yu> wrote:
> David Rickard wrote:
>
> > Don't know if this is an optimum solution, but it should work:
> > Keep a List or Vector of IDs for active users in a shared,
> > application-level object (probably ServletContext);
> > When someone logs in, search the List for the submitted ID: if not
> > present, continue with login sequence; if present, kick them to the
> > "duplicate login" page;
> > Remove IDs from the List when users log out (and add a
> > ServletContextListener to catch people who leave the site without
> > logging out--remove their IDs when their sessions time out);
>
>
> This is definitely a correct approach, but it has onw shortcoming.
> Suppose one user opens up a session (logs in) and his/her browser dies.
> The user opens another browser and tries to login, only to be kicked to
> "duplicate user" page. I think in this case, the original poster should
> have a vector or a hash map of user names and remote machine names/IPs.
>
> Nix.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
--
Virtually,
Andre Van Klaveren
Architect III, SCP
Enterprise Transformation Services
Unisys Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by Nikola Milutinovic <Ni...@ev.co.yu>.
David Rickard wrote:
> Don't know if this is an optimum solution, but it should work:
> Keep a List or Vector of IDs for active users in a shared,
> application-level object (probably ServletContext);
> When someone logs in, search the List for the submitted ID: if not
> present, continue with login sequence; if present, kick them to the
> "duplicate login" page;
> Remove IDs from the List when users log out (and add a
> ServletContextListener to catch people who leave the site without
> logging out--remove their IDs when their sessions time out);
This is definitely a correct approach, but it has onw shortcoming.
Suppose one user opens up a session (logs in) and his/her browser dies.
The user opens another browser and tries to login, only to be kicked to
"duplicate user" page. I think in this case, the original poster should
have a vector or a hash map of user names and remote machine names/IPs.
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
A SessionContextListener gets called when a session times out, or is
otherwise invalidated. This is how you do it. I did this in an app
some time ago... I just needed to maintain a list of who was logged in.
You can do something simple like I did: have a UsersList object with
a single static HashMap in it. In that HashMap goes User objects. When
the session is created, the listener is called, and you put the User
object in it. When the session is destroyed, you remove it. I keyed
the HashMap off user ID, you can do it however you like. Just be sure
to take concurrency into account and it works rather well. You could do
it to a database if your requirements make that a better choice.
Frank
Michael Mehrle wrote:
> That actually goes to the heart of my question: HOW do I detect when
> their session times out? ;-)
> I know the 'strategy' of doing this, but I don't know how to capture a
> timed-out session - technically. Any input would be welcome.
>
> TIA,
>
> Michael
>
> ----- Original Message ----- From: "David Rickard"
> <Da...@techbooks.com>
> To: "Tomcat Users List" <to...@jakarta.apache.org>
> Sent: Tuesday, June 14, 2005 9:53 AM
> Subject: Re: Concurrent login detection - how?
>
>
>
>> Remove IDs from the List when users log out (and add a
>> ServletContextListener to catch people who leave the site without logging
>> out--remove their IDs when their sessions time out);
>>
>> At 09:22 AM 6/14/2005, you wrote:
>>
>>> What is the best way to detect two people being logged in
>>> concurrently using
>>> the same account? This is one aspect of my efforts to restrict
>>> fraudulent
>>> access. Again, I don't want to use Acegi since it seems to break the
>>> rest of
>>> my app. So, what's the best way to do this 'traditionally'?
>>>
>>> Thanks!
>>>
>>> Michael
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>>
>>
>>
>> --
>>
>> David Rickard
>> Software Engineer
>>
>> TechBooks/GTS
>> Your Single Source Solution!
>> Los Angeles CA * York, PA * Boston,MA * New Delhi, India
>> Visit us on the World Wide Web
>> <http://www.techbooks.com>http://www.techbooks.com
>>
>> david.rickard@techbooks.com
>> 5650 Jillson St., Los Angeles, CA 90040
>> (323) 888-8889 x331
>> (323) 888-1849 (Fax)
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by David Rickard <Da...@techbooks.com>.
A HttpSessionListener implements a sessionDestroyed() method, which
receives a HttpSessionEvent object from the servlet container when "a
session is about to be invalidated" (the timing undoubtedly depends upon
the container); the HttpSessionEvent object has a getSession() method,
which returns the HttpSession object about to be invalidated, from which
you can get the session ID & other information to identify the affected user;
At 01:28 PM 6/14/2005, Michael Mehrle wrote:
>That actually goes to the heart of my question: HOW do I detect when their
>session times out? ;-)
>I know the 'strategy' of doing this, but I don't know how to capture a
>timed-out session - technically. Any input would be welcome.
>
>TIA,
>
>Michael
>
>----- Original Message ----- From: "David Rickard"
><Da...@techbooks.com>
>To: "Tomcat Users List" <to...@jakarta.apache.org>
>Sent: Tuesday, June 14, 2005 9:53 AM
>Subject: Re: Concurrent login detection - how?
>
>
>
>>Remove IDs from the List when users log out (and add a
>>ServletContextListener to catch people who leave the site without logging
>>out--remove their IDs when their sessions time out);
>>
>>At 09:22 AM 6/14/2005, you wrote:
>>>What is the best way to detect two people being logged in concurrently using
>>>the same account? This is one aspect of my efforts to restrict fraudulent
>>>access. Again, I don't want to use Acegi since it seems to break the rest of
>>>my app. So, what's the best way to do this 'traditionally'?
>>>
>>>Thanks!
>>>
>>>Michael
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>--
>>
>>David Rickard
>>Software Engineer
>>
>>TechBooks/GTS
>>Your Single Source Solution!
>>Los Angeles CA * York, PA * Boston,MA * New Delhi, India
>>Visit us on the World Wide Web
>><http://www.techbooks.com>http://www.techbooks.com
>>
>>david.rickard@techbooks.com
>>5650 Jillson St., Los Angeles, CA 90040
>>(323) 888-8889 x331
>>(323) 888-1849 (Fax)
>>
>
--
David Rickard
Software Engineer
TechBooks/GTS
Your Single Source Solution!
Los Angeles CA * York, PA * Boston,MA * New Delhi, India
Visit us on the World Wide Web
<http://www.techbooks.com>http://www.techbooks.com
david.rickard@techbooks.com
5650 Jillson St., Los Angeles, CA 90040
(323) 888-8889 x331
(323) 888-1849 (Fax)
Re: Concurrent login detection - how?
Posted by Michael Mehrle <mi...@datasaur.com>.
That actually goes to the heart of my question: HOW do I detect when their
session times out? ;-)
I know the 'strategy' of doing this, but I don't know how to capture a
timed-out session - technically. Any input would be welcome.
TIA,
Michael
----- Original Message -----
From: "David Rickard" <Da...@techbooks.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Tuesday, June 14, 2005 9:53 AM
Subject: Re: Concurrent login detection - how?
> Remove IDs from the List when users log out (and add a
> ServletContextListener to catch people who leave the site without logging
> out--remove their IDs when their sessions time out);
>
> At 09:22 AM 6/14/2005, you wrote:
>>What is the best way to detect two people being logged in concurrently
>>using
>>the same account? This is one aspect of my efforts to restrict fraudulent
>>access. Again, I don't want to use Acegi since it seems to break the rest
>>of
>>my app. So, what's the best way to do this 'traditionally'?
>>
>>Thanks!
>>
>>Michael
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>
>
> --
>
> David Rickard
> Software Engineer
>
> TechBooks/GTS
> Your Single Source Solution!
> Los Angeles CA * York, PA * Boston,MA * New Delhi, India
> Visit us on the World Wide Web
> <http://www.techbooks.com>http://www.techbooks.com
>
> david.rickard@techbooks.com
> 5650 Jillson St., Los Angeles, CA 90040
> (323) 888-8889 x331
> (323) 888-1849 (Fax)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Concurrent login detection - how?
Posted by David Rickard <Da...@techbooks.com>.
Don't know if this is an optimum solution, but it should work:
Keep a List or Vector of IDs for active users in a shared,
application-level object (probably ServletContext);
When someone logs in, search the List for the submitted ID: if not present,
continue with login sequence; if present, kick them to the "duplicate
login" page;
Remove IDs from the List when users log out (and add a
ServletContextListener to catch people who leave the site without logging
out--remove their IDs when their sessions time out);
At 09:22 AM 6/14/2005, you wrote:
>What is the best way to detect two people being logged in concurrently using
>the same account? This is one aspect of my efforts to restrict fraudulent
>access. Again, I don't want to use Acegi since it seems to break the rest of
>my app. So, what's the best way to do this 'traditionally'?
>
>Thanks!
>
>Michael
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
--
David Rickard
Software Engineer
TechBooks/GTS
Your Single Source Solution!
Los Angeles CA * York, PA * Boston,MA * New Delhi, India
Visit us on the World Wide Web
<http://www.techbooks.com>http://www.techbooks.com
david.rickard@techbooks.com
5650 Jillson St., Los Angeles, CA 90040
(323) 888-8889 x331
(323) 888-1849 (Fax)
Concurrent login detection - how?
Posted by Michael Mehrle <mi...@datasaur.com>.
What is the best way to detect two people being logged in concurrently using
the same account? This is one aspect of my efforts to restrict fraudulent
access. Again, I don't want to use Acegi since it seems to break the rest of
my app. So, what's the best way to do this 'traditionally'?
Thanks!
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Christian Stalp <st...@imbei.uni-mainz.de>.
> Is the path really correct? Is the webapp's directory really named
> "my_exec"?
>
> Try to use the absolute pathname of your webapp's directory, i. e.
> something like
> grant codeBase "file:/opt/tomcat-4.1/webapps/my_exec_or_whatever/-" ...
>
> Is the file really executable for the account tomcat runs under?
>
> Regards
> mks
Excuse me for a moment. Now I have the trouble that I cannot restart Tomcat
and so I had to reboot the whole system. Now tomcat start while the
bootprocess but cannot be accessed over the browser. And I don't have a
process called catalina nor tomcat !?!?!
Gruss Christian
P.S. Tomorrow Im on university again, sh****
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Markus Schönhaber <ma...@schoenhaber.de>.
Am Dienstag, 14. Juni 2005 14:52 schrieb Christian Stalp:
> I did it.
> I made this entry in catalina-policy:
>
> // Mein Eintrag zum ausführen eines Prozesses:
> grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
> permission java.io.FilePermission "/home/chris/c/file-test","execute";
> };
>
Is the path really correct? Is the webapp's directory really named "my_exec"?
Try to use the absolute pathname of your webapp's directory, i. e. something
like
grant codeBase "file:/opt/tomcat-4.1/webapps/my_exec_or_whatever/-" ...
Is the file really executable for the account tomcat runs under?
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Christian Stalp <st...@imbei.uni-mainz.de>.
I did it.
I made this entry in catalina-policy:
// Mein Eintrag zum ausführen eines Prozesses:
grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
permission java.io.FilePermission "/home/chris/c/file-test","execute";
};
Then I wrote this servlet:
[code]
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class FireStarter extends HttpServlet
{
public void doGet ( HttpServletRequest req, HttpServletResponse res ) throws
ServletException, IOException
{
int rueckgabe = 0;
rueckgabe = Fireone();
res.setContentType ( "text/html" );
PrintWriter out = res.getWriter();
out.println ( "<HTML>" );
out.println ( "<HEAD><TITLE>Firestarter</TITLE></HEAD>" );
out.println ( "<BODY>" );
out.println ( "<BIG> Firestarter </BIG>" );
out.println ( "</BODY></HTML>" );
}
public int Fireone ( )
{
int rueck_gabe = 0;
try
{
String cmd1 = "/home/chris/c/file-test";
Runtime rt = Runtime.getRuntime();
Process myproc = rt.exec( cmd1 );
rueck_gabe = myproc.waitFor();
System.out.println("die Rueckgabe war: " + rueck_gabe );
}
catch( IOException ioexc )
{
ioexc.printStackTrace();
}
catch( InterruptedException intexc )
{
intexc.printStackTrace();
}
return ( rueck_gabe );
}
}
[/code]
And I put into a package ( with WEB-INF/ the web.xml-files and so on...)
my_exec.WAR.
BUT this is the result/trace I got :-(
[quote]
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from
fulfilling this request.
exception
java.security.AccessControlException: access denied
(java.io.FilePermission /home/chris/c/file-test execute)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkExec(SecurityManager.java:771)
at java.lang.Runtime.exec(Runtime.java:563)
at java.lang.Runtime.exec(Runtime.java:428)
at java.lang.Runtime.exec(Runtime.java:364)
at java.lang.Runtime.exec(Runtime.java:326)
at FireStarter.Fireone(FireStarter.java:32)
at FireStarter.doGet(FireStarter.java:12)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:200)
at org.apache.catalina.core.ApplicationFilterChain.access$000
(ApplicationFilterChain.java:51)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
Apache Tomcat/4.1
[/quote]
What went wrong, any small detail?
Thank you...
Gruss Christian
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Christian Stalp <st...@imbei.uni-mainz.de>.
Am Montag, 13. Juni 2005 16:24 schrieb Markus Schönhaber:
> Am Montag, 13. Juni 2005 16:01 schrieb Christian Stalp:
> > But at the Moment I get an error that this is not allowed for a Servlet
> > which seems logical to me. So I have to change the catalina.policy.
> >
> > The question is now: how?
> > What I have to do, to enable my servlet to start binarys on my host?
>
> Have you even tried to use the policy-entries I posted as an answer to the
> very same question you asked on pug-talk? If so, what went wrong?
Hey Markus,
nice to meet you here at the tomcat-mailing list.
I really didn't read your answer. My Problem is, Im a student and a programer
50/50 and work for 4 projects in our institute. So sometimes you loose the
overview :-\
> ---snip---
>
> Ein grant-Eintrag im Policy-File könnte dann so aussehen:
>
> grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
> permission java.io.FilePermission "<Pfad zum aszuführenden Programm>",
> "execute";
> };
>
> Oder wenn Du Deiner WebApp vertraust:
>
> grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
> permission java.security.AllPermission;
> };
>
> ---snap---
>
> Regards
> mks
>
I'll check this in the afternoon. ;-)
Gruss Christian
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Markus Schönhaber <ma...@schoenhaber.de>.
Am Dienstag, 14. Juni 2005 14:27 schrieb Christian Stalp:
> > Ein grant-Eintrag im Policy-File könnte dann so aussehen:
> >
> > grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
> > permission java.io.FilePermission "<Pfad zum aszuführenden
> > Programm>", "execute";
> > };
>
> And the "/my_exec/-", is that the context-path?
Yes.
> That means I can call my Servlet whatever I want, but I have to put it into
> a package called my_exec.WAR ? Is that correct?
Well, kind of. The trailing "-" in the path specification above means: grant
that right to all files in this directory and all subdirectories thereof. So,
as a result, the name of your servlet really doesn't matter, since it resides
somewhere in (a subdirectoy of) the webapp-directory.
But better to see it just the other way round: you don't adopt your webapp to
match the configuration parameter but the configuration parameter to match
the webapp.
Example: the servlet that shall be able to execute an external binary is
contained a webapp named "My1stWebApp" which is placed at the default
location (i. e. the location tomcat's default configuration specifies). The
path to your webapp's directory will therefore be
${catalina.home}/webapps/My1stWebApp
and the configuration parameter
grant codeBase "file:${catalina.home}/webapps/My1stWebApp/-" ...
If you have for example placed your webapp in
/some/strange/dir/mywebapps/My1stWebApp
the entry in catalina.policy should the read
grant codeBase "file:/some/strange/dir/mywebapps/My1stWebApp/-" ...
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Christian Stalp <st...@imbei.uni-mainz.de>.
>
> Ein grant-Eintrag im Policy-File könnte dann so aussehen:
>
> grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
> permission java.io.FilePermission "<Pfad zum aszuführenden Programm>",
> "execute";
> };
And the "/my_exec/-", is that the context-path?
That means I can call my Servlet whatever I want, but I have to put it into a
package called my_exec.WAR ? Is that correct?
Gruss Christian
--
Christian Stalp
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Johannes-Gutenberg-Universität Mainz
Tel.: 06131 / 17-3107
E-Mail: stalp@imbei.uni-mainz.de
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Markus Schönhaber <ma...@schoenhaber.de>.
Am Montag, 13. Juni 2005 16:01 schrieb Christian Stalp:
>
> But at the Moment I get an error that this is not allowed for a Servlet
> which seems logical to me. So I have to change the catalina.policy.
>
> The question is now: how?
> What I have to do, to enable my servlet to start binarys on my host?
Have you even tried to use the policy-entries I posted as an answer to the
very same question you asked on pug-talk? If so, what went wrong?
---snip---
Ein grant-Eintrag im Policy-File könnte dann so aussehen:
grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
permission java.io.FilePermission "<Pfad zum aszuführenden Programm>",
"execute";
};
Oder wenn Du Deiner WebApp vertraust:
grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
permission java.security.AllPermission;
};
---snap---
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: starting a binary by calling a servlet
Posted by Markus Schönhaber <ma...@schoenhaber.de>.
Am Montag, 13. Juni 2005 16:01 schrieb Christian Stalp:
>
> But at the Moment I get an error that this is not allowed for a Servlet
> which seems logical to me. So I have to change the catalina.policy.
>
> The question is now: how?
> What I have to do, to enable my servlet to start binarys on my host?
Have you even tried to use the policy-entries I posted as an answer to the
very same question you asked on pug-talk? If so, what went wrong?
---snip---
Ein grant-Eintrag im Policy-File könnte dann so aussehen:
grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
permission java.io.FilePermission "<Pfad zum aszuführenden Programm>",
"execute";
};
Oder wenn Du Deiner WebApp vertraust:
grant codeBase "file:${catalina.home}/webapps/my_exec/-" {
permission java.security.AllPermission;
};
---snap---
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org