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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
