You are viewing a plain text version of this content. The canonical link for it is here.

Posted to derby-dev@db.apache.org by "Shane Powell (JIRA)" <de...@db.apache.org> on 2006/02/25 01:40:54 UTC

[jira] Created: (DERBY-1054) Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.

Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.
------------------------------------------------------------------------------------------------------

         Key: DERBY-1054
         URL: http://issues.apache.org/jira/browse/DERBY-1054
     Project: Derby
        Type: Bug
  Components: Network Server  
 Environment: Gentoo & RedHat Linux. 
JDK 1.5.0.  
Tomcat 5.0.28
Derby 10.1
derby.war
    Reporter: Shane Powell


I like the idea of using the NetServlet with the derby.war file inside of tomcat to allow Tomcat to start and stop my derby database.  This makes it quite easy for some of our less than technical users.   However, the NetServlet.java file appears to have "localhost" hard coded as the startup host.  This forced Derby to start listening ONLY on 127.0.0.1.  I tried passing the -Dderby.drda.host parameter through the java startup of Tomcat, but it doesn't appear to have any affect.  Ideally, the NetServlet.java class should allow for a "host" parameter to be passed in via the web.xml file.  That way we can easily control the listening interface.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Commented: (DERBY-1054) Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.

Posted by Myrna van Lunteren <m....@gmail.com>.

On 4/5/07, Bryan Pendleton <bp...@amberpoint.com> wrote:
> Myrna van Lunteren wrote:
> > I don't think
> > there's much of any warning in or near the servlet re security issues.
>
> This is an excellent point. I think it would be good to add text
> such as the following in two places:
> 1) As XML comments in the web.xml file for the host init-param
> 2) In the NetServlet documentation in the manual.
>
> The text should be something like the following (taken from the
> Network Server page):
>
>       Remember: Before using the -h option, you should run under the
>       Java security manager and enable user authentication.
>
>       By default, the Network Server will listen to requests only on
>       the loopback address, which means that it will only accept
>       connections from the local host.
>
> Do you think that would address the security concern? The default
> for the NetServlet is still "localhost", so it is the same as for
> the other out-of-the-box ways to run the Network Server.
>
> thanks,
>
> bryan
>
>
I think that would be fine.

Myrna

Re: [jira] Commented: (DERBY-1054) Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.

Posted by Bryan Pendleton <bp...@amberpoint.com>.

Myrna van Lunteren wrote:
> I don't think
> there's much of any warning in or near the servlet re security issues.

This is an excellent point. I think it would be good to add text
such as the following in two places:
1) As XML comments in the web.xml file for the host init-param
2) In the NetServlet documentation in the manual.

The text should be something like the following (taken from the
Network Server page):

       Remember: Before using the -h option, you should run under the
       Java security manager and enable user authentication.

       By default, the Network Server will listen to requests only on
       the loopback address, which means that it will only accept
       connections from the local host.

Do you think that would address the security concern? The default
for the NetServlet is still "localhost", so it is the same as for
the other out-of-the-box ways to run the Network Server.

thanks,

bryan

Re: [jira] Commented: (DERBY-1054) Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.

Posted by Myrna van Lunteren <m....@gmail.com>.

On 4/5/07, Bryan Pendleton <bp...@amberpoint.com> wrote:
> Thanks for the comments, Myrna!
>
> > I am also wondering if allowing remote servers to get started - and
> > stopped - would pose a security risk. Unless the app server is started
> > with security manager, I guess.
>
> Do you think that allowing the hostname value to be set in the web.xml
> makes the security risk worse?

Well, currently you can't use the servlet that way...I don't think it
matters much, but (and please correct me if I'm wrong) I don't think
there's much of any warning in or near the servlet re security issues.
>
> > I admit, I always interpreted the servlet more in the line of a demo
> > than a heavy-weight tool.
>
> Yes, I agree. I take your meaning to be that, since NetServlet.java uses
> public APIs of the NetworkServerControl class, anyone who wanted a more
> capable and/or secure implementation could build their own servlet code,
> using the NetServlet.java code as a starting point. Is that what you meant?
>

Yes, that's exactly what I meant.
Of course, interesting improvements would be welcomed...:-)

Myrna

Re: [jira] Commented: (DERBY-1054) Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.

Posted by Bryan Pendleton <bp...@amberpoint.com>.

Thanks for the comments, Myrna!

> I am also wondering if allowing remote servers to get started - and
> stopped - would pose a security risk. Unless the app server is started
> with security manager, I guess.

Do you think that allowing the hostname value to be set in the web.xml
makes the security risk worse?

> I admit, I always interpreted the servlet more in the line of a demo
> than a heavy-weight tool.

Yes, I agree. I take your meaning to be that, since NetServlet.java uses
public APIs of the NetworkServerControl class, anyone who wanted a more
capable and/or secure implementation could build their own servlet code,
using the NetServlet.java code as a starting point. Is that what you meant?

thanks,

bryan