tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [OT] Memory Leak in Tomcat
Date Fri, 25 Feb 2011 15:47:06 GMT
chris derham wrote:
> All,
> 
> I've only been on this mailing list for a couple of weeks, so am still not
> quite sure of the etiquette. I know people get upset about top posting

I think that's more a matter of personal preference.
It makes it a bit harder sometimes to connect a response with the original question, 
because you have to scroll etc..

  or
> replying to an existing email and changing the subject only.

That is more annoying, because quite a few people have their client set to display 
messages "by thread" (a hierarchical display where messages neatly appear under the ones 
they respond to, instead of just chronologically).  The client classifies new messages as

being "part of a thread" using information contained in other headers within the message 
(kind of a "refers to" thing).  These headers are automatically added by the list server.
So when you respond to an existing message and change the subject, for these people an 
unrelated message suddenly appears inside a discussion "tree" where your new message does

not belong. (And you'll probably be ignored, except for a short "don't hijack threads" 
injunction).
Thus, if you respond to an existing message, hitting the "reply" button is OK.
If you write a message about a new subject, then don't do that.
Create a new message, with a new subject, and address it to the list.
It will then become the top of a new thread.

  Not sure about
> the intricacies of when people should attempt to help others on the list. I
> assume anybody can chip in at anytime - please let me know otherwise.
> 

Please do.  That's the point of this list.
Specially interventions like yours, which is civil, well-written and brings valuable 
information and insights.


> Having said this, I can't bear to see this thread anymore without chipping
> in. I understood from the original post that this inquiry was about a
> problem whereby a move from having db credentials stored in tomcat config to
> having windows service credentials used to log into the database. Once this
> happened, a memory leak occurred. Some suggestions were made as to how to
> track this down, and since then the thread has drifted into a discussion
> about the merits of this approach, and now seems to be tittering on the edge
> of a discussion about the merits of true SSO.

That's why someone at some point changed the subject to add the [OT] (Off-Topic) marker.
That's a case by the way where changing the subject is ok, because it still somehow 
belongs to the same thread.

  I just wanted to address the
> first two points.
> 
> The posts indicate that the service was run as local system. Moving to a
> domain user to make things simpler doesn't really add up for me. You've now
> exposed the whole network to the hacker - if they can break into the tomcat
> process, any action they perform will potentially have access to any network
> resource as the process is a domain user. 

You're right, and I didn't even think of that aspect.

The OP didn't detail the topology
> of the network, and if the webserver is on a DMZ with a firewall between it
> and the rest of the network. This may or not be more worrying than having
> the ability to read the password.
> 
> If a hacker gets onto your webserver, there are a couple of scenarios.
> Either they break into the tomcat process and are constrained in it, or get
> full control of the whole server. The thought process of all people
> discussing this on this thread is that if they can read the password to the
> db, they can then get into the database and do bad things. 

Not of everyone.  But it seemed to be the thought process of the OP.

Hackers are
> human, and as such lazy. It is far simpler to craft a fairly simple jsp
> page, that allows posting arbitrary SQL to the same jsp, which then asks
> tomcat for a connection, and then runs the SQL and displays the results.
> Doesn't matter how you store the password/token to access the database, once
> this jsp is in place they still got the ability to execute arbitrary SQL. So
> any discussions about which method is better to store the password are
> something of a moot point.
>
Agreed.

> Security recommendations suggest that you should secure the db to least
> privs. So the db should only accept connections from the webserver IP. So
> the ability to read the password really isn't such a big thing - if they can
> read it, they can only access the db from the webserver.
> 
> Security recommendations suggest that you should secure the webserver to run
> tomcat with least privs. If you store username and password using plain
> text, you can run the service as a dedicated local user on the machine. When
> configured correctly, this will constrain what the hackers can do if they
> break into the tomcat process - e.g. they can only access tomcat files and
> no other files on the webserver. This is less risk than running as a domain
> account IMHO
> 
Totally agreed.  I must say that I generally dislike the OP's whole setup, for the reason

that the DB is now incapable of distinguishing one real user from the other, since they 
all come in through the Tomcat user-id.
In addition, one will have to give this Tomcat user-id extensive privileges to the DB, 
because it has to cover all the requests that all real users may make.
...

The only caveat, is if one of the Tomcat applications needs access to some Windows network

resource (such as a shared disk directory on a server). The way Windows Domain 
authentication works, you will then need to run Tomcat as a domain user.

> 
> Hope that helps
> 
> Chris
> 
Personally, I think it did.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message