You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Dan Sandberg <x...@cs.stanford.edu> on 2002/05/01 10:00:11 UTC
SSI Servlet has big problems
Hi everyone.
I ran into bug #6299 today (two server-side includes fail with buffering
on), did some debugging, and found the cause of it.
I have no doubt that a bunch of other bugs in bugzilla are caused by the
same issue.
Basically, the class and its helper classes have a pretty serious design
flaw: they declare lots of information static ( like the servlet output
stream ) that should not be shared between threads and/or instances of
the servlet.
Specifically, SsiInvokerServlet.java declares SsiMediator as static.
SsiMediator in turn declares LOTS of things static, like the request,
response, output stream, etc.
This is probably causing garbled output, socket closed errors, etc. when
multiple users are viewing .shtml files at the same time and/or when
users are viewing output with buffered=true.
Implementing the SingleThreadedServlet interface will not help this problem.
Are the two authors still mantaining this code? Bip Thelin? Amy Roh?
-Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Dan Sandberg wrote:
>
> >
> >
> >Dan Sandberg wrote:
> >
> >
> >>I'll be done with the SSI rewrite tomorrow.
> >>
> >>I'd like to get the community's advice on a number of issues:
> >>
> >>1-I changed the names of the files from Ssi... to SSI... This seems to
> >>be more consistent with the naming scheme of other files, and made
> >>things easier for me since I did a gradual rewrite of everything. This
> >>will make it harder to see what I changed when I submit a diff,
> >>however. I changed 75% of everything, so I'm not sure this matters. Is
> >>it ok?
> >>
> >>
> >>
> >
> >Thats fine, please put the SSI servlet code into a sub package in servlet
> >also. i.e. org.apache.catalina.servlet.ssi.*.
> >
> >
>
> Write now the servlet (one class) is in: org.apache.catalina.servlets
> While all its supporting classes are in: org.apache.catalina.util.ssi
>
> I propose moving all the SSI support classes to: org.apache.catalina.ssi
>
> They don't belong in servlet, since they CAN be used without a servlet (
> for example, in a filter ) and they prob. don't belong in util, since
> they can't be used by anything other than the SSIServlet, and the SSIFilter.
>
> >>2-What's the story with the SSI jar having the .renametojar extension?
> >> I'm surmising that this is because this class will be loaded under the
> >>system class loader rather than the user servlet class loader, causing
> >>the #exec functionality to be a security risk. Can't we just have a
> >>directory where we put servlets that should be loaded under the 'safe'
> >>class loader?
> >>
> >>
> >>
> >
> >Yes, this is so SSI can not be used without the admin explicitely enabling
> >it by renaming the jar. Whether the Runtime.exec() method can be called
> >is dependent upon the catalina.policy, not on what ClassLoader is used.
> >
> >I have proposed a reorganization of the servlets into sub packages in
> >org.apache.catalina.servlets. In addition moving the jar files for the
> >servlets into a separate directory. /server/servlets for those which require
> >access to privileged internal catalina code, and /shared/servlets for those
> >which do not require access to privileged catalina code.
> >
> Sounds good. Why is this not a problem with JSP pages then? How is
> doing an exec in SSI different than doing a Runtime.exec in JSP?
>
Security! I do not allow Runtime.exec() to be used in JSP pages on
instances of Tomcat I administer. That could be a huge security hole.
I use the Java SecurityManager and a strict catalina.policy to prevent it.
I also don't install either the SSI or CGI servlets for security reasons.
Because both of these are a potential security risk they are disabled in
the Tomcat distribution.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
>
>
>Dan Sandberg wrote:
>
>
>>I'll be done with the SSI rewrite tomorrow.
>>
>>I'd like to get the community's advice on a number of issues:
>>
>>1-I changed the names of the files from Ssi... to SSI... This seems to
>>be more consistent with the naming scheme of other files, and made
>>things easier for me since I did a gradual rewrite of everything. This
>>will make it harder to see what I changed when I submit a diff,
>>however. I changed 75% of everything, so I'm not sure this matters. Is
>>it ok?
>>
>>
>>
>
>Thats fine, please put the SSI servlet code into a sub package in servlet
>also. i.e. org.apache.catalina.servlet.ssi.*.
>
>
Write now the servlet (one class) is in: org.apache.catalina.servlets
While all its supporting classes are in: org.apache.catalina.util.ssi
I propose moving all the SSI support classes to: org.apache.catalina.ssi
They don't belong in servlet, since they CAN be used without a servlet (
for example, in a filter ) and they prob. don't belong in util, since
they can't be used by anything other than the SSIServlet, and the SSIFilter.
>>2-What's the story with the SSI jar having the .renametojar extension?
>> I'm surmising that this is because this class will be loaded under the
>>system class loader rather than the user servlet class loader, causing
>>the #exec functionality to be a security risk. Can't we just have a
>>directory where we put servlets that should be loaded under the 'safe'
>>class loader?
>>
>>
>>
>
>Yes, this is so SSI can not be used without the admin explicitely enabling
>it by renaming the jar. Whether the Runtime.exec() method can be called
>is dependent upon the catalina.policy, not on what ClassLoader is used.
>
>I have proposed a reorganization of the servlets into sub packages in
>org.apache.catalina.servlets. In addition moving the jar files for the
>servlets into a separate directory. /server/servlets for those which require
>access to privileged internal catalina code, and /shared/servlets for those
>which do not require access to privileged catalina code.
>
Sounds good. Why is this not a problem with JSP pages then? How is
doing an exec in SSI different than doing a Runtime.exec in JSP?
-Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Dan Sandberg wrote:
>
> I'll be done with the SSI rewrite tomorrow.
>
> I'd like to get the community's advice on a number of issues:
>
> 1-I changed the names of the files from Ssi... to SSI... This seems to
> be more consistent with the naming scheme of other files, and made
> things easier for me since I did a gradual rewrite of everything. This
> will make it harder to see what I changed when I submit a diff,
> however. I changed 75% of everything, so I'm not sure this matters. Is
> it ok?
>
Thats fine, please put the SSI servlet code into a sub package in servlet
also. i.e. org.apache.catalina.servlet.ssi.*.
> 2-What's the story with the SSI jar having the .renametojar extension?
> I'm surmising that this is because this class will be loaded under the
> system class loader rather than the user servlet class loader, causing
> the #exec functionality to be a security risk. Can't we just have a
> directory where we put servlets that should be loaded under the 'safe'
> class loader?
>
Yes, this is so SSI can not be used without the admin explicitely enabling
it by renaming the jar. Whether the Runtime.exec() method can be called
is dependent upon the catalina.policy, not on what ClassLoader is used.
I have proposed a reorganization of the servlets into sub packages in
org.apache.catalina.servlets. In addition moving the jar files for the
servlets into a separate directory. /server/servlets for those which require
access to privileged internal catalina code, and /shared/servlets for those
which do not require access to privileged catalina code.
> 3-Right now the SSIServlet has an initialization parameter to determine
> whether unsupported commands ( #foobar ) should be ignored. It seems
> like the issue should be more complicated than this. There is a
> difference between #foobar and #if. #foobar is not supported by anyone,
> and should be handled the same way apache would do it ( echo an error ).
> #if however, IS handled by apache, and is not handled by the
> SSIServlet. Therefore it seems that the initialization parameter
> mentioned should only apply to the latter case. Personally I think this
> initialization parameter should be axed completely, as I don't see where
> its use solves more problems that it creates. For example, if a person
> did have code that used #if, #else, etc., then by ignoring these
> directives we'd end up making the output be even weirder ( and with no
> explanation of why! ) than if we just stuck [an error occurred while
> processing this directive] all over the place.
>
> 4-Right now we are not logging invalid atribute names ( --#echo
> nonExistantAttribute="foobar" -- ), or logging invalid commands, or
> logging invalid settings for attributes ( --#echo
> encoding="noSuchEncoding" var="DOCUMENT_NAME" -- ). Apache logs this
> stuff, it seems like we should too. Where do I log it to ( what
> classes/methods do I use )? Should there be a way to turn this logging off?
>
> 5-The command <#echo var='SOMETHING'> is not too useful right now,
> because what SOMETHING can be is highly constrained.
> I'd like to make so that this command searches the request attributes (
> for a variable named SOMETHING ). This will make this servlet more
> useful when writing filters that use it. More importantly, it lets
> existing users who are using SSI already have more power without needing
> to rewrite their .shtml files in .jsp. [The company that I consult for
> said they would find this useful, so I'm not making this up] I'd like to
> also implement the #set command, so that it sets a variable in the
> request. Anyone have objections to this?
>
> 6-This servlet has the option of being buffered or unbuffered. Can
> someone explain to me why this is useful? The SSIServlet should never
> throw an error, so I don't see why this would matter.
>
> Thanks,
>
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
I'll be done with the SSI rewrite tomorrow.
I'd like to get the community's advice on a number of issues:
1-I changed the names of the files from Ssi... to SSI... This seems to
be more consistent with the naming scheme of other files, and made
things easier for me since I did a gradual rewrite of everything. This
will make it harder to see what I changed when I submit a diff,
however. I changed 75% of everything, so I'm not sure this matters. Is
it ok?
2-What's the story with the SSI jar having the .renametojar extension?
I'm surmising that this is because this class will be loaded under the
system class loader rather than the user servlet class loader, causing
the #exec functionality to be a security risk. Can't we just have a
directory where we put servlets that should be loaded under the 'safe'
class loader?
3-Right now the SSIServlet has an initialization parameter to determine
whether unsupported commands ( #foobar ) should be ignored. It seems
like the issue should be more complicated than this. There is a
difference between #foobar and #if. #foobar is not supported by anyone,
and should be handled the same way apache would do it ( echo an error ).
#if however, IS handled by apache, and is not handled by the
SSIServlet. Therefore it seems that the initialization parameter
mentioned should only apply to the latter case. Personally I think this
initialization parameter should be axed completely, as I don't see where
its use solves more problems that it creates. For example, if a person
did have code that used #if, #else, etc., then by ignoring these
directives we'd end up making the output be even weirder ( and with no
explanation of why! ) than if we just stuck [an error occurred while
processing this directive] all over the place.
4-Right now we are not logging invalid atribute names ( --#echo
nonExistantAttribute="foobar" -- ), or logging invalid commands, or
logging invalid settings for attributes ( --#echo
encoding="noSuchEncoding" var="DOCUMENT_NAME" -- ). Apache logs this
stuff, it seems like we should too. Where do I log it to ( what
classes/methods do I use )? Should there be a way to turn this logging off?
5-The command <#echo var='SOMETHING'> is not too useful right now,
because what SOMETHING can be is highly constrained.
I'd like to make so that this command searches the request attributes (
for a variable named SOMETHING ). This will make this servlet more
useful when writing filters that use it. More importantly, it lets
existing users who are using SSI already have more power without needing
to rewrite their .shtml files in .jsp. [The company that I consult for
said they would find this useful, so I'm not making this up] I'd like to
also implement the #set command, so that it sets a variable in the
request. Anyone have objections to this?
6-This servlet has the option of being buffered or unbuffered. Can
someone explain to me why this is useful? The SSIServlet should never
throw an error, so I don't see why this would matter.
Thanks,
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Bill Barker <wb...@wilshire.com>.
The standard way is to attach the output of "cvs diff" to an e-mail message
with a subject beginning with the string "[PATCH]". If you continue to make
work for us enough by doing this, eventually someone will propose you as a
committer :-).
----- Original Message -----
From: "Dan Sandberg" <x...@cs.stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, May 01, 2002 9:39 PM
Subject: Re: SSI Servlet has big problems
> Remy Maucherat wrote:
>
> >>Implementing the SingleThreadedServlet interface will not help thi
> >>
> >
> >Are you sure ?
> >(I didn't look at the code at all, so I'm just wondering)
> >Otherwise, it would be a really cheap way to make it work.
> >
> >Thanks for looking into it anyway.
> >
> >
>
> Implementing SingleThreadedServlet doesn't mean only one thread will be
> running the servlet at a time. It means only one thread will be running
> a given INSTANCE of the servlet. So you could still have two threads
> running two different instances of the same servlet. This will still
> get massively messed up with all the sharing of static variables.
>
> >>Are the two authors still mantaining this code? Bip Thelin? Amy Roh?
> >>
> >>
> >
> >Not really. I didn't hear about Bip for a while, and Amy has been busy
with
> >other things.
> >Usually an easy way to get commit access if you have time to dedicate to
> >contributing is to take over the maintenance of some abandoned
component(s).
> >CGI also needs a maintainer, BTW.
> >
> >Remy
> >
> I'll fix this problem, and I'll create a filter that does SSI on any
> output ( so that a JSP page can use SSI, for example ). I don't have
> any interest in being a maintainer/having commit access, however.
>
> So what's the best way to give back my bug fixes/filter?
>
> Thanks for the response, btw.
>
> -Dan
>
>
>
> --
> 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: SSI Servlet has big problems
Posted by Dan Sandberg <x...@cs.stanford.edu>.
Remy Maucherat wrote:
>>Implementing the SingleThreadedServlet interface will not help thi
>>
>
>Are you sure ?
>(I didn't look at the code at all, so I'm just wondering)
>Otherwise, it would be a really cheap way to make it work.
>
>Thanks for looking into it anyway.
>
>
Implementing SingleThreadedServlet doesn't mean only one thread will be
running the servlet at a time. It means only one thread will be running
a given INSTANCE of the servlet. So you could still have two threads
running two different instances of the same servlet. This will still
get massively messed up with all the sharing of static variables.
>>Are the two authors still mantaining this code? Bip Thelin? Amy Roh?
>>
>>
>
>Not really. I didn't hear about Bip for a while, and Amy has been busy with
>other things.
>Usually an easy way to get commit access if you have time to dedicate to
>contributing is to take over the maintenance of some abandoned component(s).
>CGI also needs a maintainer, BTW.
>
>Remy
>
I'll fix this problem, and I'll create a filter that does SSI on any
output ( so that a JSP page can use SSI, for example ). I don't have
any interest in being a maintainer/having commit access, however.
So what's the best way to give back my bug fixes/filter?
Thanks for the response, btw.
-Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SSI Servlet has big problems
Posted by Remy Maucherat <re...@apache.org>.
> Hi everyone.
>
> I ran into bug #6299 today (two server-side includes fail with buffering
> on), did some debugging, and found the cause of it.
>
> I have no doubt that a bunch of other bugs in bugzilla are caused by the
> same issue.
>
> Basically, the class and its helper classes have a pretty serious design
> flaw: they declare lots of information static ( like the servlet output
> stream ) that should not be shared between threads and/or instances of
> the servlet.
>
> Specifically, SsiInvokerServlet.java declares SsiMediator as static.
> SsiMediator in turn declares LOTS of things static, like the request,
> response, output stream, etc.
>
> This is probably causing garbled output, socket closed errors, etc. when
> multiple users are viewing .shtml files at the same time and/or when
> users are viewing output with buffered=true.
>
> Implementing the SingleThreadedServlet interface will not help this
problem.
Are you sure ?
(I didn't look at the code at all, so I'm just wondering)
Otherwise, it would be a really cheap way to make it work.
Thanks for looking into it anyway.
> Are the two authors still mantaining this code? Bip Thelin? Amy Roh?
Not really. I didn't hear about Bip for a while, and Amy has been busy with
other things.
Usually an easy way to get commit access if you have time to dedicate to
contributing is to take over the maintenance of some abandoned component(s).
CGI also needs a maintainer, BTW.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>