You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by הילה <hi...@gmail.com> on 2011/02/20 14:28:30 UTC
Memory Leak in Tomcat
Hey,
I work in a company which we use Tomcat (5.5.26 and recently we've upgraded
it to 6.0.29) to run our application.
The tomcat is running on servers with OS windows 2008 R2 STD.
The problem is-
Until now, we used [b]SQL Authentication[/b] for the tomcat service and
configuration (user and password for tomcat to access the DB was provided
within the xml configuration file, under c:\Program Files\Apache Software
Foundation\Tomcat 6.0\conf\catalina\localhost), but! since we changed
configuration to use [b]Windows Authentication [/b](the user that runs
tomcat is now a domain user with permissions on the DB + removed user and
password from xml configuration file), we observed a trend of memory leak,
where it comes to attention by the process of tomcat, which is increasing on
a daily basis.
do you know why is it happening?
and what can I do to stop the memory leak (other than switching back to SQL
authentication).
any suggestions via mail (hilavalensia@gmail.com) would be highly
appreciated.
Thanks
Hila
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Sorry for the sent mail double time thing :]
i'll check the Jespa suggestion. thanks :]
keep the ideas coming, guys. every little thing could help
Thanks
Hila
2011/2/23 André Warnier <aw...@ice-sa.com>
> הילה wrote:
>
>> I've posted my problem in the sourceforge forums, but no comments have
>> received so far. :(
>>
>> If you have any suggestions to replace this, another way to authenticate
>> the
>> tomcat to the DB with user and password that do not appear in clear text,
>> I'll be glad to hear about it.
>>
>> Have a look at Jespa (http://www.ioplex.com)
>
> In the basic configuration, it works a bit differently : it authenticates
> (with Windows Domain) the user who is *using* the Tomcat application, not
> the Tomcat process itself.
> (*)
>
> However, it comes with an API which can probably be used to do what you
> want.
> Send an email to support@ioplex.com explaining what you want to achieve,
> and I am sure that they will tell you if Jespa can be used for that.
>
>
>
> (*) Note the difference : currently, you are authenticating to the DB with
> the single "Tomcat user". So all the users of your application really
> access the database under this one "group-id". Anyone who can connect to
> Tomcat, can get data out of the database, under this one user-id. That may
> or may not be secure, depending on how the users authenticate to the Tomcat
> application.
>
> In the Jespa kind of setup, a java servlet filter picks up the Windows
> Domain user-id of the user accessing the Tomcat application.
> This same user-id can then be picked up inside the application via
> getRemoteUser() (or something sismilar), and used to connect to the
> database.
> Then you really filter accesses to the database by individual user-id.
>
> One or the other setup may be what you really need, but that you have to
> decide yourself.
>
>
> P.S.
> There is no need to send me a copy of each message that you send to the
> list.
> I receive all messages to the list anyway (as do the other subscribers), so
> when you copy me, I get the same message twice.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
הילה wrote:
> I've posted my problem in the sourceforge forums, but no comments have
> received so far. :(
>
> If you have any suggestions to replace this, another way to authenticate the
> tomcat to the DB with user and password that do not appear in clear text,
> I'll be glad to hear about it.
>
Have a look at Jespa (http://www.ioplex.com)
In the basic configuration, it works a bit differently : it authenticates (with Windows
Domain) the user who is *using* the Tomcat application, not the Tomcat process itself.
(*)
However, it comes with an API which can probably be used to do what you want.
Send an email to support@ioplex.com explaining what you want to achieve, and I am sure
that they will tell you if Jespa can be used for that.
(*) Note the difference : currently, you are authenticating to the DB with the single
"Tomcat user". So all the users of your application really access the database under this
one "group-id". Anyone who can connect to Tomcat, can get data out of the database, under
this one user-id. That may or may not be secure, depending on how the users authenticate
to the Tomcat application.
In the Jespa kind of setup, a java servlet filter picks up the Windows Domain user-id of
the user accessing the Tomcat application.
This same user-id can then be picked up inside the application via getRemoteUser() (or
something sismilar), and used to connect to the database.
Then you really filter accesses to the database by individual user-id.
One or the other setup may be what you really need, but that you have to decide yourself.
P.S.
There is no need to send me a copy of each message that you send to the list.
I receive all messages to the list anyway (as do the other subscribers), so when you copy
me, I get the same message twice.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
I know it has its advantages, that's why I used it :]
but if the memory leak will continue, and I won't figure it out, I think I'd
have to start looking for alternate possibilities
Thanks
Hila
2011/2/24 Jeffrey Janner <Je...@polydyne.com>
> > -----Original Message-----
> > From: Christopher Schultz [mailto:chris@christopherschultz.net]
> > Sent: Wednesday, February 23, 2011 10:11 AM
> > To: Tomcat Users List
> > Subject: Re: [OT] Memory Leak in Tomcat
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > הילה,
> >
> > On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote:
> > > the user that runs the tomcat service is a domain user, but I specify
> > the
> > > user name and password of this user under "log on" tab on the service
> > > properties.
> > > it's not a problem since the password is encrypted, but in the xml
> > file it's
> > > in clear text.
> >
> > It's a good thing those credentials don't need to be decrypted in order
> > to be used. Congratulations: you've covered your ass.
> >
>
> Not sure exactly what Windows does once you've entered a verified user/pw
> combination for a service. I'm guessing that it stores the password
> somehow, because if you change the password, the service won't start next
> time.
>
> However, this is a "nice" (?) feature of using SQL Server. Already
> validated user credentials can be passed by the OS to SQL Server to be
> validated for database logon. It's their version of SSO for the database.
> (Note: I don't find it an overwhelming advantage for determining to use that
> specific database software.)
> __________________________________________________________________________
>
> Confidentiality Notice: This Transmission (including any attachments) may
> contain information that is privileged, confidential, and exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient you are hereby notified that any dissemination,
> distribution, or copying of this communication is strictly prohibited.
>
> If you have received this transmission in error, please immediately reply
> to the sender or telephone (512) 343-9100 and delete this transmission from
> your system.
>
RE: [OT] Memory Leak in Tomcat
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: peter.crowther3@googlemail.com
> [mailto:peter.crowther3@googlemail.com] On Behalf Of Peter Crowther
> Sent: Thursday, February 24, 2011 3:57 AM
> To: Tomcat Users List
> Subject: Re: [OT] Memory Leak in Tomcat
>
> On 24 February 2011 09:42, André Warnier <aw...@ice-sa.com> wrote:
>
> > Jeffrey Janner wrote:
> > ..
> >
> >>
> >>>
> >> Not sure exactly what Windows does once you've entered a verified
> user/pw
> >> combination for a service. I'm guessing that it stores the password
> >> somehow, because if you change the password, the service won't start
> next
> >> time.
> >>
> >>
> > It is stored in whatever format, encrypted or not or hashed or not,
> in
> > whatever store the Domain Controller uses to store user credentials.
> > It doesn't matter.
> > NTLM authentication afterward works using "tokens" which somehow
> encode the
> > information needed by a server to verify that the client is who it
> says it
> > is, and the server is who it says it is.
> > The point is that the password is not stored in clear on the client,
> when
> > "client" means whatever host is trying to authenticate itself. It is
> of
> > coursee fleetingly in memory at some point, to construct the
> authentication
> > tokens, but is not kept. Only the token is kept.
> >
> > André, I'd be interested in how you arrived at these assertions. In
> particular, I don't believe your first sentence. I can start a service
> that
> logs on as a domain account when my domain member (a laptop) is not
> connected to the domain. Therefore the domain member is storing
> something
> somewhere, not just the DC. And any time "something" is stored
> "somewhere"
> it is subject to attack, as the Linux-based tools for changing Windows
> administrator passwords demonstrate rather well - Windows may not allow
> direct SAM hive access, but a foreign OS has no such compunctions.
>
The local Windows OS caches logon credentials and does a local authentication iff the domain controller is not available -- specifically for the purpose of allowing logins in that case. Those credentials are stored somewhere on disk (probably somewhere under C:\Windows\security, or perhaps in the registry), and potentially usable by an attacker. However, if the credentials cannot be verified by other networked machines, those systems are supposed to reject them.
My original point was that I don't know the mechanism for storing credentials in the Services. It appears that they are store in the registry, but I cannot tell if they are encryptions of the credentials themselves or the token returned from authentication. In either case, if you change the password on the domain, you have to change it on the service or it won't start.
> This is all a long way from the original subject, of course. I
> routinely
> use SSPI authentication to SQL Server when I can do, as it does reduce
> the
> attack surface somewhat. SSPI generally makes it harder for an
> attacker to
> retrieve the credentials used to authenticate a database client to SQL
> Server. It makes no difference to any attack that subverts the client
> directly in order to attack through an existing or client-created new
> connection, of course.
>
> - Peter
p.s. before the spell-check nazi's comment on it, the "iff" above was intentional.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by Peter Crowther <pe...@melandra.com>.
On 24 February 2011 09:42, André Warnier <aw...@ice-sa.com> wrote:
> Jeffrey Janner wrote:
> ..
>
>>
>>>
>> Not sure exactly what Windows does once you've entered a verified user/pw
>> combination for a service. I'm guessing that it stores the password
>> somehow, because if you change the password, the service won't start next
>> time.
>>
>>
> It is stored in whatever format, encrypted or not or hashed or not, in
> whatever store the Domain Controller uses to store user credentials.
> It doesn't matter.
> NTLM authentication afterward works using "tokens" which somehow encode the
> information needed by a server to verify that the client is who it says it
> is, and the server is who it says it is.
> The point is that the password is not stored in clear on the client, when
> "client" means whatever host is trying to authenticate itself. It is of
> coursee fleetingly in memory at some point, to construct the authentication
> tokens, but is not kept. Only the token is kept.
>
> André, I'd be interested in how you arrived at these assertions. In
particular, I don't believe your first sentence. I can start a service that
logs on as a domain account when my domain member (a laptop) is not
connected to the domain. Therefore the domain member is storing something
somewhere, not just the DC. And any time "something" is stored "somewhere"
it is subject to attack, as the Linux-based tools for changing Windows
administrator passwords demonstrate rather well - Windows may not allow
direct SAM hive access, but a foreign OS has no such compunctions.
This is all a long way from the original subject, of course. I routinely
use SSPI authentication to SQL Server when I can do, as it does reduce the
attack surface somewhat. SSPI generally makes it harder for an attacker to
retrieve the credentials used to authenticate a database client to SQL
Server. It makes no difference to any attack that subverts the client
directly in order to attack through an existing or client-created new
connection, of course.
- Peter
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey,
On 2/25/2011 11:13 AM, Jeffrey Janner wrote:
> Thanks for adding some more well-thought-out reasoning to this
> discussion. You've pointed out some issues that the rest of us had
> addressed, or even thought about, and pointing out that real security
> is always about more than just the simplified checkbox requirements
> that some security wonkos live by.
I'm wondering if any of this discussion can be rolled-into this page:
http://wiki.apache.org/tomcat/FAQ/Password
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1n86cACgkQ9CaO5/Lv0PBGRgCfYp8UMuQViRiASnFpSP3Mi7Kx
uioAoKKPaQNKpvEK8B/augWw5mZFURO4
=99Tv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
Chris -
Thanks for adding some more well-thought-out reasoning to this discussion.
You've pointed out some issues that the rest of us had addressed, or even thought about, and pointing out that real security is always about more than just the simplified checkbox requirements that some security wonkos live by.
This "plaintext password" discussion happens on this list about once every other month on this list in response to someone querying about it. The argument usually comes down to "if the hacker can read the config file, you've already got bigger problems."
You've actually added some points that I've not seen before that deserve some serious consideration. Kudos.
Jeff
p.s. top-posting because it's a commentary on all that follows. You don't have to read to the bottom to see my minor comments.
> -----Original Message-----
> From: cjderham@gmail.com [mailto:cjderham@gmail.com] On Behalf Of chris
> derham
> Sent: Friday, February 25, 2011 3:55 AM
> To: Tomcat Users List
> Subject: Re: [OT] Memory Leak in Tomcat
>
> 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
> or
> replying to an existing email and changing the subject only. 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.
>
> 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. 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. 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. 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.
>
> 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
>
> > I trust the people in the company, but the company's work is with
> sites
> that
> > any user all over the internet can access. so we want to perform a
> damage
> > control if some hacker would gain access to our web server, so if he
> can -
> > he won't get access to the DB, at least not with our help of
> displaying
> the
> > user and password to access the DB :].
>
> So secure these other sites, such that they can't access this website.
> e.g.
> run the other sites as local user A and run your site as local user B.
> That
> way your concern is potentially mitigated, as long as the hacker only
> takes
> control of the other sites process. An alternative would be to separate
> the
> two sets of sites, either on separate physical machines, or using a
> virtual
> machine and a physical machine, or multiple virtual machines. That way
> if
> they break into these other sites, they won't have access to your site
> or
> its configuration.
>
> There is a tool http://www.jasypt.org/encrypting-configuration.html
> which
> allows you to store the configuration information in an encrypted form.
> I
> mention it as this might appease some less technical/ceo/manager type
> people
> and it might help you to tick any security check list that says "no
> passwords in clear text". However be sure to understand this won't
> make
> your site any more secure. If someone can obtain access to the config
> file
> containing plain text password, when the setting is encrypted they
> would
> still be able to access the encrypted one and find the key used to
> unencrypt
> it.
>
> Hope that helps
>
> Chris
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
On 2/25/2011 4:54 AM, chris derham wrote:
> 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.
True, but we were presuming that the server hasn't been configured to
allow remote users to write to the filesystem. Sure, we were making a
whole bunch of assumptions, here. :)
The original assertion was something along the lines of "cleartext
passwords in server.xml aren't secure enough". My contention is that if
your box is compromised, you're fucked either way. If you have access to
the user that runs Tomcat, you can read the password right out of
server.xml. If you have that same access, you're right: you can just
install whatever software you want into Tomcat and then have full access
to the database (well, to the extent that the database allows).
> 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.
Exactly. That's why I was saying that switching from plaintext
authentication to NTLM (or whatever) doesn't really buy you more
security. Unless you don't trust the OS's ability to protect your files
from unauthorized users, none of these strategies buy you anything other
than being able to check-off a box on some naive security checklist.
I nearly got into a yelling match with a security auditor who told me
that encryption keys and encrypted data should never be at the same
place at the same time. "How do you ever access the data, then?" I
asked. He told me that it was a "best practice" to never have the data
and the key in the same place at the same time. My brain nearly exploded.
> There is a tool http://www.jasypt.org/encrypting-configuration.html which
> allows you to store the configuration information in an encrypted form. I
> mention it as this might appease some less technical/ceo/manager type people
> and it might help you to tick any security check list that says "no
> passwords in clear text". However be sure to understand this won't make
> your site any more secure. If someone can obtain access to the config file
> containing plain text password, when the setting is encrypted they would
> still be able to access the encrypted one and find the key used to unencrypt
> it.
Yup: moving the problem.
Thanks for your thoughts.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1n8WUACgkQ9CaO5/Lv0PDTaACcDIvTSwPotOZWq1hinX4FC7A8
0E0AoJYBOx6N/9QHa00ou4cCKNpUVaRx
=cRep
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: הילה [mailto:hilavalensia@gmail.com]
> Subject: Re: [OT] Memory Leak in Tomcat
> How can I encrypt the password inside the xml file?
Short answer: pointless exercise.
Long answer: search the archives.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Re: tomcat server
Posted by Jeff Hubbs <jh...@att.net>.
If you use "localhost2" as a URL, you will almost certainly get an error
because that name is unlikely to resolve to a system that is set up to
provide a Web service to your browser. If you get an error when using
the URL "localhost", that is because the machine you're running that
browser on ("localhost", by convention, always refers to the machine on
which the network host reference is being made) does not have a Web
service configured to respond on IP port 80, which, also by convention,
is the default port number for http traffic. It works when you use
"localhost:8080" because 8080 is the default IP port on which Tomcat
receives Web traffic. So, your arrangement is working exactly as one
would expect.
On 3/10/11 12:36 PM, ken dias wrote:
> Questions:1. how to get response (not error) when i type localhost2. why does it work in one case and not the other
> please don't try to be funny, answer the question or don't reply
>
>> From: Chuck.Caldarale@unisys.com
>> To: users@tomcat.apache.org
>> Date: Thu, 10 Mar 2011 11:16:38 -0600
>> Subject: RE: tomcat server
>>
>>> From: ken dias [mailto:kendias@hotmail.com]
>>> Subject: tomcat server
>>> I started the Tomcat webserver. When I keyin "localhost:8080",
>>> I get the apache-tomcat webpage and can run the examples.
>>> however, when i keyin "localhost" only, i get error.
>> As you should. Do you have a question?
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Hey,
i've posted a message on JTDS forums, but no one answered.
I know the memory leak is caused by the dll, since when I don't use it, all
is good.
i'll open a new thread here, thanks
2011/3/6 André Warnier <aw...@ice-sa.com>
> הילה wrote:
>
>> Security seems to be always in the hands of the wrong people.
>>
>> No need for insults here, this is a new requirement which I'm not familiar
>> with, and that's why I asked you guys..
>>
>>
>> Instead of the JTDS, can I use Tomcat Spengo?
>> will it provide same results, as using a domain user for the tomcat
>> windows
>> service, and removing user and password from xml configuration file under
>> conf/catalina/localhost ?
>>
>>
> Maybe it is time to "rewind", and restart from the beginning, before the
> thread degenerated into a discussion about the comparative aspects of
> security etc..
>
> I gather that by now, you must have established that the memory leak was
> not in Tomcat per se, but in the jDTS/jTDS driver, and/or the .dll that it
> is using for Windows-based authentication, right ?
>
> If so, maybe you want start another new thread, with a more appropriate
> subject ?
> (If so, do not hit "reply", start a new message to the list)
>
> Also, did you ever ask the jDTS/jTDS people about this memory leak, and did
> you ever get an answer ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
הילה wrote:
> Security seems to be always in the hands of the wrong people.
>
> No need for insults here, this is a new requirement which I'm not familiar
> with, and that's why I asked you guys..
>
>
> Instead of the JTDS, can I use Tomcat Spengo?
> will it provide same results, as using a domain user for the tomcat windows
> service, and removing user and password from xml configuration file under
> conf/catalina/localhost ?
>
Maybe it is time to "rewind", and restart from the beginning, before the thread
degenerated into a discussion about the comparative aspects of security etc..
I gather that by now, you must have established that the memory leak was not in Tomcat per
se, but in the jDTS/jTDS driver, and/or the .dll that it is using for Windows-based
authentication, right ?
If so, maybe you want start another new thread, with a more appropriate subject ?
(If so, do not hit "reply", start a new message to the list)
Also, did you ever ask the jDTS/jTDS people about this memory leak, and did you ever get
an answer ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: tomcat server
Posted by ken dias <ke...@hotmail.com>.
thanks for a clear answer.
Ken
> Date: Thu, 10 Mar 2011 12:41:06 -0500
> Subject: Re: tomcat server
> From: jr@tabbysplace.org
> To: users@tomcat.apache.org
>
> When you enter localhost:8080 the browser treis to speak to a server
> on port 8080, where Tomcat runs by default.
>
> When you just enter localhost, the browser uses the default HTTP port
> of 80. Presumably, you do not have a server listening to that port.
>
> Make sense?
>
> --
> Jonathan Rosenberg
> Founder & Executive Director
> Tabby's Place, a Cat Sanctuary
> http://www.tabbysplace.org/
>
>
> On Thu, Mar 10, 2011 at 12:36 PM, ken dias <ke...@hotmail.com> wrote:
> >
> > Questions:1. how to get response (not error) when i type localhost2. why does it work in one case and not the other
> > please don't try to be funny, answer the question or don't reply
> >
> >> From: Chuck.Caldarale@unisys.com
> >> To: users@tomcat.apache.org
> >> Date: Thu, 10 Mar 2011 11:16:38 -0600
> >> Subject: RE: tomcat server
> >>
> >> > From: ken dias [mailto:kendias@hotmail.com]
> >> > Subject: tomcat server
> >>
> >> > I started the Tomcat webserver. When I keyin "localhost:8080",
> >> > I get the apache-tomcat webpage and can run the examples.
> >> > however, when i keyin "localhost" only, i get error.
> >>
> >> As you should. Do you have a question?
> >>
> >> - Chuck
> >>
> >>
> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: tomcat server
Posted by Jonathan Rosenberg <jr...@tabbysplace.org>.
When you enter localhost:8080 the browser treis to speak to a server
on port 8080, where Tomcat runs by default.
When you just enter localhost, the browser uses the default HTTP port
of 80. Presumably, you do not have a server listening to that port.
Make sense?
--
Jonathan Rosenberg
Founder & Executive Director
Tabby's Place, a Cat Sanctuary
http://www.tabbysplace.org/
On Thu, Mar 10, 2011 at 12:36 PM, ken dias <ke...@hotmail.com> wrote:
>
> Questions:1. how to get response (not error) when i type localhost2. why does it work in one case and not the other
> please don't try to be funny, answer the question or don't reply
>
>> From: Chuck.Caldarale@unisys.com
>> To: users@tomcat.apache.org
>> Date: Thu, 10 Mar 2011 11:16:38 -0600
>> Subject: RE: tomcat server
>>
>> > From: ken dias [mailto:kendias@hotmail.com]
>> > Subject: tomcat server
>>
>> > I started the Tomcat webserver. When I keyin "localhost:8080",
>> > I get the apache-tomcat webpage and can run the examples.
>> > however, when i keyin "localhost" only, i get error.
>>
>> As you should. Do you have a question?
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: tomcat server
Posted by ken dias <ke...@hotmail.com>.
Questions:1. how to get response (not error) when i type localhost2. why does it work in one case and not the other
please don't try to be funny, answer the question or don't reply
> From: Chuck.Caldarale@unisys.com
> To: users@tomcat.apache.org
> Date: Thu, 10 Mar 2011 11:16:38 -0600
> Subject: RE: tomcat server
>
> > From: ken dias [mailto:kendias@hotmail.com]
> > Subject: tomcat server
>
> > I started the Tomcat webserver. When I keyin "localhost:8080",
> > I get the apache-tomcat webpage and can run the examples.
> > however, when i keyin "localhost" only, i get error.
>
> As you should. Do you have a question?
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: tomcat server
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: ken dias [mailto:kendias@hotmail.com]
> Subject: tomcat server
> I started the Tomcat webserver. When I keyin "localhost:8080",
> I get the apache-tomcat webpage and can run the examples.
> however, when i keyin "localhost" only, i get error.
As you should. Do you have a question?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat server
Posted by David Smith <da...@cornell.edu>.
Perfectly normal .... browsers assume port 80 when you don't offer a
port number in the url. Your tomcat instance is not listening on port
80 and won't be able to respond when you try to access it there.
Solution: change the port number in your tomcat's server.xml file and
restart.
--David
On 3/10/2011 12:13 PM, ken dias wrote:
>
>
> I started the Tomcat webserver. When I keyin "localhost:8080", I get the apache-tomcat webpage and can run the examples. however, when i keyin "localhost" only, i get error.
>
> Thanks,
> Ken
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
tomcat server
Posted by ken dias <ke...@hotmail.com>.
I started the Tomcat webserver. When I keyin "localhost:8080", I get the apache-tomcat webpage and can run the examples. however, when i keyin "localhost" only, i get error.
Thanks,
Ken
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Thanks :]
This was the task I was required to do, wit no question asked, cause this is
a requirement for our application to pass some major barriers. so.. :]
Hila
2011/3/7 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 3/6/2011 4:49 AM, הילה wrote:
> > > Security seems to be always in the hands of the wrong people.
> >
> > No need for insults here, this is a new requirement which I'm not
> familiar
> > with, and that's why I asked you guys..
>
> I don't think Jorge was trying to make a disparaging comment about you,
> here. Instead, I think he was trying to point out that often, the people
> who are making the security decisions are removed enough from the actual
> technology that they don't really understand what they're doing.
>
> In fact, I apologize if my exasperation at your task seems directed at
> you: I merely wanted you to acknowledge that your task was ultimately no
> more secure than a cleartext password in a file with proper permissions.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk10O1sACgkQ9CaO5/Lv0PDjMQCdGXpS9t1YQMRDQykys8rPopLe
> TjEAn3exSJM773TZnlIZkU6UW3XbhJFm
> =c2B9
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 3/6/2011 4:49 AM, הילה wrote:
> > Security seems to be always in the hands of the wrong people.
>
> No need for insults here, this is a new requirement which I'm not familiar
> with, and that's why I asked you guys..
I don't think Jorge was trying to make a disparaging comment about you,
here. Instead, I think he was trying to point out that often, the people
who are making the security decisions are removed enough from the actual
technology that they don't really understand what they're doing.
In fact, I apologize if my exasperation at your task seems directed at
you: I merely wanted you to acknowledge that your task was ultimately no
more secure than a cleartext password in a file with proper permissions.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk10O1sACgkQ9CaO5/Lv0PDjMQCdGXpS9t1YQMRDQykys8rPopLe
TjEAn3exSJM773TZnlIZkU6UW3XbhJFm
=c2B9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Security seems to be always in the hands of the wrong people.
No need for insults here, this is a new requirement which I'm not familiar
with, and that's why I asked you guys..
Instead of the JTDS, can I use Tomcat Spengo?
will it provide same results, as using a domain user for the tomcat windows
service, and removing user and password from xml configuration file under
conf/catalina/localhost ?
Thanks
Hila
2011/3/2 Jorge Medina <ce...@gmail.com>
> I got a good laugh with your message.
>
> Security seems to be always in the hands of the wrong people.
>
> Once I asked for the algorithm used to hash the passwords (that
> happened to be HMAC SHA-1) into a database, if I was going to
> authenticate the users, I needed to use the same algorithm. I did not
> ask for the key used to salt the hash, I could put that as a parameter
> to be provided at install time and use any other key during
> development and testing. My request was rejected until authorized by a
> manager two levels up! <sigh> (All I needed to know was "HMAC
> SHA-1"!)
>
>
>
>
> On Mon, Feb 28, 2011 at 11:02 AM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > הילה,
> >
> > On 2/28/2011 5:17 AM, הילה wrote:
> >> How can I encrypt the password inside the xml file?
> >
> > 0. $file = conf/server.xml
> > 1. Use your favorite encryption tool to encrypt the password and shove
> > it into $file
> > 2. Use that same tool in some code you hack-into Tomcat to read it
> > back out.
> > 3. Store the key to your favorite-tool encryption package in another
> > file (say, s3cr3t.key)
> > 4. $file = s3cr3t.key
> > 5. Go to step 1.
> >
> > Repeat this process until you feel like you're safe. (Hint: you are
> > still not safe). Scratch that: repeat this process until your boss or
> > your auditor feel like they are safe.
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1
> > ikgAn1xQNqRRtSKby531xKRHizxzEFwD
> > =uuFd
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by Jorge Medina <ce...@gmail.com>.
I got a good laugh with your message.
Security seems to be always in the hands of the wrong people.
Once I asked for the algorithm used to hash the passwords (that
happened to be HMAC SHA-1) into a database, if I was going to
authenticate the users, I needed to use the same algorithm. I did not
ask for the key used to salt the hash, I could put that as a parameter
to be provided at install time and use any other key during
development and testing. My request was rejected until authorized by a
manager two levels up! <sigh> (All I needed to know was "HMAC
SHA-1"!)
On Mon, Feb 28, 2011 at 11:02 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/28/2011 5:17 AM, הילה wrote:
>> How can I encrypt the password inside the xml file?
>
> 0. $file = conf/server.xml
> 1. Use your favorite encryption tool to encrypt the password and shove
> it into $file
> 2. Use that same tool in some code you hack-into Tomcat to read it
> back out.
> 3. Store the key to your favorite-tool encryption package in another
> file (say, s3cr3t.key)
> 4. $file = s3cr3t.key
> 5. Go to step 1.
>
> Repeat this process until you feel like you're safe. (Hint: you are
> still not safe). Scratch that: repeat this process until your boss or
> your auditor feel like they are safe.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1
> ikgAn1xQNqRRtSKby531xKRHizxzEFwD
> =uuFd
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/28/2011 5:17 AM, הילה wrote:
> How can I encrypt the password inside the xml file?
0. $file = conf/server.xml
1. Use your favorite encryption tool to encrypt the password and shove
it into $file
2. Use that same tool in some code you hack-into Tomcat to read it
back out.
3. Store the key to your favorite-tool encryption package in another
file (say, s3cr3t.key)
4. $file = s3cr3t.key
5. Go to step 1.
Repeat this process until you feel like you're safe. (Hint: you are
still not safe). Scratch that: repeat this process until your boss or
your auditor feel like they are safe.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1rxwwACgkQ9CaO5/Lv0PCtGQCgtxVxV9+N0AvRuYw0U6mi9ki1
ikgAn1xQNqRRtSKby531xKRHizxzEFwD
=uuFd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
continue to the discussion-
How can I encrypt the password inside the xml file?
Thanks
Hila
בתאריך 27 בפברואר 2011 19:37, מאת הילה <hi...@gmail.com>:
> Original:
> Does this happen all the time? Under what conditions? Are you able to
> build a patched version of Tomcat in a test environment to test a fix I
> have? What version of Java and Tomcat are you running?
>
> Hey
> I'm not sure if you refer the question to me, since the whole topic shifted
> to an off topic :]
> But yes, it happens all the time. what do you mean "under what conditions?"
>
> As I specified in my first mail, it happens when I implement windows
> authentication on tomcat
> I use tomcat 6.0.29 , on OS win server 2008 R2 standard, JDK 1.6 Build 23
>
> If you have a fix, I'll happy to try it on our test environment.
>
> Thanks
> Hila
>
>
> 2011/2/25 Christopher Schultz <ch...@christopherschultz.net>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> André,
>>
>> On 2/25/2011 10:47 AM, André Warnier wrote:
>> > [Thread hijacking] 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.
>>
>> Worse are mail clients who think that "subject" and "thread" are
>> interchangeable: the thread-id in the SMTP headers is ignored and
>> instead the subject is used to thread things. That way, two things happen:
>>
>> 1. People who hijack threads can't tell and get all angry when we tell
>> them they hijacked the thread
>>
>> 2. Legitimate thread-subject-changes (such as adding [OT] or whatever)
>> end up showing-up in what looks like a separate thread.
>>
>> > Please do [chip in]. That's the point of this list.
>> > Specially interventions like yours, which is civil, well-written and
>> > brings valuable information and insights.
>>
>> Mostly everyone here will ignore most of the list-etiquette rules and
>> remain civil if you have something worthwhile to say. Top-posting is
>> only irritating when it looks like this:
>>
>> Reply:
>>
>> Yes, no, and maybe. There are other times this happens. 1.6. 5.something.
>>
>> Original:
>> Does this happen all the time? Under what conditions? Are you able to
>> build a patched version of Tomcat in a test environment to test a fix I
>> have? What version of Java and Tomcat are you running?
>>
>> Since Chris's post had actual content and didn't really have a
>> point-counterpoint feel to it, top-posting can be forgiven :)
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A
>> CmYAnA/117/lOPYzoKPvU9DOX29BeEFS
>> =Xzcc
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Original:
Does this happen all the time? Under what conditions? Are you able to
build a patched version of Tomcat in a test environment to test a fix I
have? What version of Java and Tomcat are you running?
Hey
I'm not sure if you refer the question to me, since the whole topic shifted
to an off topic :]
But yes, it happens all the time. what do you mean "under what conditions?"
As I specified in my first mail, it happens when I implement windows
authentication on tomcat
I use tomcat 6.0.29 , on OS win server 2008 R2 standard, JDK 1.6 Build 23
If you have a fix, I'll happy to try it on our test environment.
Thanks
Hila
2011/2/25 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> On 2/25/2011 10:47 AM, André Warnier wrote:
> > [Thread hijacking] 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.
>
> Worse are mail clients who think that "subject" and "thread" are
> interchangeable: the thread-id in the SMTP headers is ignored and
> instead the subject is used to thread things. That way, two things happen:
>
> 1. People who hijack threads can't tell and get all angry when we tell
> them they hijacked the thread
>
> 2. Legitimate thread-subject-changes (such as adding [OT] or whatever)
> end up showing-up in what looks like a separate thread.
>
> > Please do [chip in]. That's the point of this list.
> > Specially interventions like yours, which is civil, well-written and
> > brings valuable information and insights.
>
> Mostly everyone here will ignore most of the list-etiquette rules and
> remain civil if you have something worthwhile to say. Top-posting is
> only irritating when it looks like this:
>
> Reply:
>
> Yes, no, and maybe. There are other times this happens. 1.6. 5.something.
>
> Original:
> Does this happen all the time? Under what conditions? Are you able to
> build a patched version of Tomcat in a test environment to test a fix I
> have? What version of Java and Tomcat are you running?
>
> Since Chris's post had actual content and didn't really have a
> point-counterpoint feel to it, top-posting can be forgiven :)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A
> CmYAnA/117/lOPYzoKPvU9DOX29BeEFS
> =Xzcc
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 2/25/2011 10:47 AM, André Warnier wrote:
> [Thread hijacking] 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.
Worse are mail clients who think that "subject" and "thread" are
interchangeable: the thread-id in the SMTP headers is ignored and
instead the subject is used to thread things. That way, two things happen:
1. People who hijack threads can't tell and get all angry when we tell
them they hijacked the thread
2. Legitimate thread-subject-changes (such as adding [OT] or whatever)
end up showing-up in what looks like a separate thread.
> Please do [chip in]. That's the point of this list.
> Specially interventions like yours, which is civil, well-written and
> brings valuable information and insights.
Mostly everyone here will ignore most of the list-etiquette rules and
remain civil if you have something worthwhile to say. Top-posting is
only irritating when it looks like this:
Reply:
Yes, no, and maybe. There are other times this happens. 1.6. 5.something.
Original:
Does this happen all the time? Under what conditions? Are you able to
build a patched version of Tomcat in a test environment to test a fix I
have? What version of Java and Tomcat are you running?
Since Chris's post had actual content and didn't really have a
point-counterpoint feel to it, top-posting can be forgiven :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1n8uwACgkQ9CaO5/Lv0PDHNQCfXscF1JWtPIXeu3DMzLgFbg/A
CmYAnA/117/lOPYzoKPvU9DOX29BeEFS
=Xzcc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: [OT] Memory Leak in Tomcat
Posted by chris derham <ch...@derham.me.uk>.
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 or
replying to an existing email and changing the subject only. 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.
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. 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. 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. 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.
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
> I trust the people in the company, but the company's work is with sites
that
> any user all over the internet can access. so we want to perform a damage
> control if some hacker would gain access to our web server, so if he can -
> he won't get access to the DB, at least not with our help of displaying
the
> user and password to access the DB :].
So secure these other sites, such that they can't access this website. e.g.
run the other sites as local user A and run your site as local user B. That
way your concern is potentially mitigated, as long as the hacker only takes
control of the other sites process. An alternative would be to separate the
two sets of sites, either on separate physical machines, or using a virtual
machine and a physical machine, or multiple virtual machines. That way if
they break into these other sites, they won't have access to your site or
its configuration.
There is a tool http://www.jasypt.org/encrypting-configuration.html which
allows you to store the configuration information in an encrypted form. I
mention it as this might appease some less technical/ceo/manager type people
and it might help you to tick any security check list that says "no
passwords in clear text". However be sure to understand this won't make
your site any more secure. If someone can obtain access to the config file
containing plain text password, when the setting is encrypted they would
still be able to access the encrypted one and find the key used to unencrypt
it.
Hope that helps
Chris
Re: [OT] Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
Jeffrey Janner wrote:
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Thursday, February 24, 2011 3:43 AM
>> To: Tomcat Users List
>> Subject: Re: [OT] Memory Leak in Tomcat
>>
>> Jeffrey Janner wrote:
>> ..
>>> Not sure exactly what Windows does once you've entered a verified
>> user/pw combination for a service. I'm guessing that it stores the
>> password somehow, because if you change the password, the service won't
>> start next time.
>> It is stored in whatever format, encrypted or not or hashed or not, in
>> whatever store the
>> Domain Controller uses to store user credentials.
>> It doesn't matter.
>> NTLM authentication afterward works using "tokens" which somehow encode
>> the information
>> needed by a server to verify that the client is who it says it is, and
>> the server is who
>> it says it is.
>> The point is that the password is not stored in clear on the client,
>> when "client" means
>> whatever host is trying to authenticate itself. It is of coursee
>> fleetingly in memory at
>> some point, to construct the authentication tokens, but is not kept.
>> Only the token is kept.
>>
>>
>>> However, this is a "nice" (?) feature of using SQL Server. Already
>> validated user credentials can be passed by the OS to SQL Server to be
>> validated for database logon. It's their version of SSO for the
>> database. (Note: I don't find it an overwhelming advantage for
>> determining to use that specific database software.)
>>
>> No it isn't, not in this case.
>>
>> in the current scenario, the "user" for which there is SSO is the user-
>> id under which the
>> Tomcat process itself is running. It is /not/ the users which connect
>> to Tomcat and run
>> the applications.
>> All these users connect to Tomcat, and are or not authenticated using
>> whatever method
>> Tomcat implements.
>> But then, the credentials used to connect to the database are the
>> credentials of the
>> Tomcat process, not the ones of the users.
>> That is why is was questioning how much in fact of a security this
>> brings.
>> The problem is merely moved, to the level of how users authenticate
>> with the Tomcat
>> application. Once they have done that, they can access any information
>> which is accessible
>> by this Tomcat user.
>>
>
> Isn't that the point of authentication in the application/Tomcat? (Note, I'm intentionally misinterpreting your use of the term "Tomcat user" here, as you seem to be mixing the different authentication levels in your argument.)
>
> Here's the proper setup the OP is attempting to implement:
> 1: End user's authenticate the application using whatever method they deem necessary.
> 2: Tomcat/application authenticates to SQL Server either via plaintext uid & pw stored in XML file, or via SSO token derived from Tomcat process login.
> The differences:
> a) The plaintext is available rather easily to anyone who can access said XML file, either via Tomcat or some other means. Those credentials can be used to launch an attack on the DB from the Tomcat server, or any other server.
> b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it and the attack must take place via the Tomcat process.
> c) It is probably possible to grab the Windows SSO token used by the Tomcat process by locating it on disk and somehow making it useable for attacking the SQL Db. I don't tread too deeply in the security waters, but I think that would have made big news if it was easy.
>
> Note: I'm not particularly trying to argue that this is an "ultimately secure" mechanism for authenticating Tomcat to the SQL Server database. But it does allow the checking of the box next to "No passwords stored in cleartext" line on the security gestapo's checklist.
Hi.
I agree with all of the above, and maybe I did not say it clearly, but that is also what I
meant.
1) authenticating the Tomcat process to the DB system by means of an NTLM-based
authentication, is a degree more secure than via a clear-text userid/password combination,
because it this last case, the userid/password combination have to be stored somewhere on
the Tomcat server in clear.
2) this however, by itself, does /not/ provide a Single-Sign-On capability for the users,
at least not vis-a-vis the DB system. A true user-level SSO would have the *user*
credentials being used to authenticate to the DB system, which is not the case here.
The only user authenticatiing to the DB system, is whatever user-id Tomcat runs under.
3) This is what I meant by "merely displacing the issue" : whichever user is "accepted" by
Tomcat can now use the Tomcat applications to access the contents of the database. That
is because Tomcat is authenticated to the DB system, and all accesses to the DB are made
by Tomcat under its own user-id.
So now the issue is : how (and even if) the users authenticate to Tomcat.
(The OP did not mention that part).
Let me give a stupid example : imagine that Tomcat authenticates users by means of the
conf/tomcat-users.xml file.
Then getting hold of /that/ file would allow anyone to login to Tomcat, and automatically
gain access to the database (through the Tomcat applications) without any further check.
Also, because there in fact a single user (Tomcat) accessing the DB system, on behalf of
multiple real users, the type of access granted in the DB system to this "Tomcat user"
must by force be very broad. In other words, if 99% of the users of the Tomcat
applications need only read access to some information, but 1% of these users need also
write access to it, you will have to give the "Tomcat user" r/w access.
Which means that now the only way of preventing the other 99% to write there, is to do it
at the application level.
4) a real secure system (and SSO mechanism) would have the users authenticating to Tomcat
via a secure method, and the Tomcat application using those same user credentials to
authenticate to the DB system on behalf of the user.
This way, the DB system would know who is accessing it, and be able to grant access or not
to selective information, based on who the user is.
But from what I understand, that is not what the OP's jDTS/ntlmauth.dll combination does.
It does obtain the "Tomcat user" credentials, and logs in to the DB system using those.
On the other hand, a servlet filter like Jespa authenticates the real user accessing the
Tomcat application, and allows the Tomcat application to use these credentials to
authenticate to a further service.
It is another philosophy and another kind of setup, and I am sure that there is room in
this world for both of them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Thursday, February 24, 2011 3:43 AM
> To: Tomcat Users List
> Subject: Re: [OT] Memory Leak in Tomcat
>
> Jeffrey Janner wrote:
> ..
> >>
> >
> > Not sure exactly what Windows does once you've entered a verified
> user/pw combination for a service. I'm guessing that it stores the
> password somehow, because if you change the password, the service won't
> start next time.
> >
>
> It is stored in whatever format, encrypted or not or hashed or not, in
> whatever store the
> Domain Controller uses to store user credentials.
> It doesn't matter.
> NTLM authentication afterward works using "tokens" which somehow encode
> the information
> needed by a server to verify that the client is who it says it is, and
> the server is who
> it says it is.
> The point is that the password is not stored in clear on the client,
> when "client" means
> whatever host is trying to authenticate itself. It is of coursee
> fleetingly in memory at
> some point, to construct the authentication tokens, but is not kept.
> Only the token is kept.
>
>
> > However, this is a "nice" (?) feature of using SQL Server. Already
> validated user credentials can be passed by the OS to SQL Server to be
> validated for database logon. It's their version of SSO for the
> database. (Note: I don't find it an overwhelming advantage for
> determining to use that specific database software.)
>
> No it isn't, not in this case.
>
> in the current scenario, the "user" for which there is SSO is the user-
> id under which the
> Tomcat process itself is running. It is /not/ the users which connect
> to Tomcat and run
> the applications.
> All these users connect to Tomcat, and are or not authenticated using
> whatever method
> Tomcat implements.
> But then, the credentials used to connect to the database are the
> credentials of the
> Tomcat process, not the ones of the users.
> That is why is was questioning how much in fact of a security this
> brings.
> The problem is merely moved, to the level of how users authenticate
> with the Tomcat
> application. Once they have done that, they can access any information
> which is accessible
> by this Tomcat user.
>
Isn't that the point of authentication in the application/Tomcat? (Note, I'm intentionally misinterpreting your use of the term "Tomcat user" here, as you seem to be mixing the different authentication levels in your argument.)
Here's the proper setup the OP is attempting to implement:
1: End user's authenticate the application using whatever method they deem necessary.
2: Tomcat/application authenticates to SQL Server either via plaintext uid & pw stored in XML file, or via SSO token derived from Tomcat process login.
The differences:
a) The plaintext is available rather easily to anyone who can access said XML file, either via Tomcat or some other means. Those credentials can be used to launch an attack on the DB from the Tomcat server, or any other server.
b) The SSO is available directly iff the attacker manages to crash Tomcat or infect it and the attack must take place via the Tomcat process.
c) It is probably possible to grab the Windows SSO token used by the Tomcat process by locating it on disk and somehow making it useable for attacking the SQL Db. I don't tread too deeply in the security waters, but I think that would have made big news if it was easy.
Note: I'm not particularly trying to argue that this is an "ultimately secure" mechanism for authenticating Tomcat to the SQL Server database. But it does allow the checking of the box next to "No passwords stored in cleartext" line on the security gestapo's checklist.
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: [OT] Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
Jeffrey Janner wrote:
..
>>
>
> Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time.
>
It is stored in whatever format, encrypted or not or hashed or not, in whatever store the
Domain Controller uses to store user credentials.
It doesn't matter.
NTLM authentication afterward works using "tokens" which somehow encode the information
needed by a server to verify that the client is who it says it is, and the server is who
it says it is.
The point is that the password is not stored in clear on the client, when "client" means
whatever host is trying to authenticate itself. It is of coursee fleetingly in memory at
some point, to construct the authentication tokens, but is not kept. Only the token is kept.
> However, this is a "nice" (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.)
No it isn't, not in this case.
in the current scenario, the "user" for which there is SSO is the user-id under which the
Tomcat process itself is running. It is /not/ the users which connect to Tomcat and run
the applications.
All these users connect to Tomcat, and are or not authenticated using whatever method
Tomcat implements.
But then, the credentials used to connect to the database are the credentials of the
Tomcat process, not the ones of the users.
That is why is was questioning how much in fact of a security this brings.
The problem is merely moved, to the level of how users authenticate with the Tomcat
application. Once they have done that, they can access any information which is accessible
by this Tomcat user.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] Memory Leak in Tomcat
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Wednesday, February 23, 2011 10:11 AM
> To: Tomcat Users List
> Subject: Re: [OT] Memory Leak in Tomcat
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote:
> > the user that runs the tomcat service is a domain user, but I specify
> the
> > user name and password of this user under "log on" tab on the service
> > properties.
> > it's not a problem since the password is encrypted, but in the xml
> file it's
> > in clear text.
>
> It's a good thing those credentials don't need to be decrypted in order
> to be used. Congratulations: you've covered your ass.
>
Not sure exactly what Windows does once you've entered a verified user/pw combination for a service. I'm guessing that it stores the password somehow, because if you change the password, the service won't start next time.
However, this is a "nice" (?) feature of using SQL Server. Already validated user credentials can be passed by the OS to SQL Server to be validated for database logon. It's their version of SSO for the database. (Note: I don't find it an overwhelming advantage for determining to use that specific database software.)
__________________________________________________________________________
Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
I'll try to check what you suggested. sounds like something that maybe shed
some light on this issue.
Thanks :]
2011/2/23 André Warnier <aw...@ice-sa.com>
> הילה wrote:
>
>> Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler
>> for a weak until it generated a stuck process on the DB and crashed the
>> application (even though it ran on the app server, and not the DB server)
>> I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try
>> to
>> go over your mail again and see if I can extract from it something that I
>> can work with :]
>>
>> I hate to barge in (again?) in what is starting to look like a nice
> slinging match, but I think that we have already pretty much established
> that the memory leak, if any, happens in the jDTS (?) driver and/or the
> ntlmauth.dll that it is using, and not in Tomcat code.
>
> If it is in the ntlmauth.dll, I doubt that any Java tool will show
> anything.
>
> הילה, how exactly are you seeing that the Tomcat process is leaking memory
> ?
> With the MS Task Manager ?
>
> And, where exactly does that ntlmauth.dll come from ?
>
>
> @Chris :
> Apparently, the database being used accepts either plain text
> authentication, or NTLM authentication.
> And apparently also, the setup is such that in either case, the login to
> the database is done using a single user-id, provided "by Tomcat".
> One can discuss if this is, in the general scheme of things, an appropriate
> way in terms of security of access to the data in the database.
> But in the case of plain text authentication, the user-id and password used
> are stored in a Tomcat configuration file, in plain text.
> In the case of the NTLM authentication, the user-id under which tomcat runs
> can be easily discovered, but the password cannot.
> So I would think that in that limited sense, using NTLM offers an
> improvement.
>
> Now of course if at the same time, a bug in the jDTS driver or the
> ntlmauth.dll causes the Tomcat process to need more and more memory over
> time, the advantage is less evident.
>
>
> To nevertheless make some progress at identifying the culprit, I suggest
> the following procedure :
>
> Leave the user-id under which Tomcat itself is running as it is, using the
> Windows Domain user. Also leave the database as it is.
> But change back the authentication used for the database, to the plain-text
> setting.
> This way, the jDTS driver will still be there, but it will no longer be
> using the additional dll, and will authenticate to the DB with the
> plain-text user-id and password.
>
> Then check if the Tomcat process is still leaking memory.
> If it is not, then you know for sure that the leak is in ntlmauth.dll (or
> in the jDTS driver, but only when it using NTLM authentication).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
הילה wrote:
> Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler
> for a weak until it generated a stuck process on the DB and crashed the
> application (even though it ran on the app server, and not the DB server)
> I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to
> go over your mail again and see if I can extract from it something that I
> can work with :]
>
I hate to barge in (again?) in what is starting to look like a nice slinging match, but I
think that we have already pretty much established that the memory leak, if any, happens
in the jDTS (?) driver and/or the ntlmauth.dll that it is using, and not in Tomcat code.
If it is in the ntlmauth.dll, I doubt that any Java tool will show anything.
הילה, how exactly are you seeing that the Tomcat process is leaking memory ?
With the MS Task Manager ?
And, where exactly does that ntlmauth.dll come from ?
@Chris :
Apparently, the database being used accepts either plain text authentication, or NTLM
authentication.
And apparently also, the setup is such that in either case, the login to the database is
done using a single user-id, provided "by Tomcat".
One can discuss if this is, in the general scheme of things, an appropriate way in terms
of security of access to the data in the database.
But in the case of plain text authentication, the user-id and password used are stored in
a Tomcat configuration file, in plain text.
In the case of the NTLM authentication, the user-id under which tomcat runs can be easily
discovered, but the password cannot.
So I would think that in that limited sense, using NTLM offers an improvement.
Now of course if at the same time, a bug in the jDTS driver or the ntlmauth.dll causes the
Tomcat process to need more and more memory over time, the advantage is less evident.
To nevertheless make some progress at identifying the culprit, I suggest the following
procedure :
Leave the user-id under which Tomcat itself is running as it is, using the Windows Domain
user. Also leave the database as it is.
But change back the authentication used for the database, to the plain-text setting.
This way, the jDTS driver will still be there, but it will no longer be using the
additional dll, and will authenticate to the DB with the plain-text user-id and password.
Then check if the Tomcat process is still leaking memory.
If it is not, then you know for sure that the leak is in ntlmauth.dll (or in the jDTS
driver, but only when it using NTLM authentication).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Yes, I've read you other mail about the Jprofiler. I've run the Jprofiler
for a weak until it generated a stuck process on the DB and crashed the
application (even though it ran on the app server, and not the DB server)
I'm not too familiar with Tomcat tweaks and java monitoring, so i'll try to
go over your mail again and see if I can extract from it something that I
can work with :]
Thanks
Hila
2011/2/23 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote:
> > the user that runs the tomcat service is a domain user, but I specify the
> > user name and password of this user under "log on" tab on the service
> > properties.
> > it's not a problem since the password is encrypted, but in the xml file
> it's
> > in clear text.
>
> It's a good thing those credentials don't need to be decrypted in order
> to be used. Congratulations: you've covered your ass.
>
> > so.. the problem for me is the memory leak that generated after switching
> to
> > windows authentication.
>
> Yup. Let's get back to that. See my other post about working with
> JProfiler.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1lMawACgkQ9CaO5/Lv0PAKpQCfeM8Qb+ixI0U+o6vukJDEAgIa
> LuYAoKz94msoMkU2+lCJ+mgY2iVvAuEH
> =Q9Rk
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/23/2011 10:51 AM, הילה - צוות אגורה wrote:
> the user that runs the tomcat service is a domain user, but I specify the
> user name and password of this user under "log on" tab on the service
> properties.
> it's not a problem since the password is encrypted, but in the xml file it's
> in clear text.
It's a good thing those credentials don't need to be decrypted in order
to be used. Congratulations: you've covered your ass.
> so.. the problem for me is the memory leak that generated after switching to
> windows authentication.
Yup. Let's get back to that. See my other post about working with JProfiler.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lMawACgkQ9CaO5/Lv0PAKpQCfeM8Qb+ixI0U+o6vukJDEAgIa
LuYAoKz94msoMkU2+lCJ+mgY2iVvAuEH
=Q9Rk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה - צוות אגורה <hi...@agora.co.il>.
Hey,
the user that runs the tomcat service is a domain user, but I specify the
user name and password of this user under "log on" tab on the service
properties.
it's not a problem since the password is encrypted, but in the xml file it's
in clear text.
so.. the problem for me is the memory leak that generated after switching to
windows authentication.
2011/2/23 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/23/2011 10:38 AM, הילה wrote:
> > I've explained it in my mail :]
> > change the user that runs the tomcat service to a domain user with
> > permissions to the DB
>
> So the domain user is password-less? How does the service start without
> credentials?
>
> I'm not actually stupid: I'm just asking stupid questions to lead you to
> the conclusion that the credentials are in fact somewhere. Just because
> you can't see them (Windows has them hidden somewhere) doesn't mean
> they're not there.
>
> You are just moving the problem somewhere else.
>
> This problem is discussed seasonally around here.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1lLB8ACgkQ9CaO5/Lv0PA87wCfdhGwBHUiutC766MH+8x5g6Zy
> NfIAoJkUCY7ZPD8EKEJvkdZHkTEEs6cj
> =+Vwc
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/23/2011 10:38 AM, הילה wrote:
> I've explained it in my mail :]
> change the user that runs the tomcat service to a domain user with
> permissions to the DB
So the domain user is password-less? How does the service start without
credentials?
I'm not actually stupid: I'm just asking stupid questions to lead you to
the conclusion that the credentials are in fact somewhere. Just because
you can't see them (Windows has them hidden somewhere) doesn't mean
they're not there.
You are just moving the problem somewhere else.
This problem is discussed seasonally around here.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lLB8ACgkQ9CaO5/Lv0PA87wCfdhGwBHUiutC766MH+8x5g6Zy
NfIAoJkUCY7ZPD8EKEJvkdZHkTEEs6cj
=+Vwc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
I've explained it in my mail :]
change the user that runs the tomcat service to a domain user with
permissions to the DB
place ntlmauth.dll (from jtds-1.2.5 package) under c:\windows\system32
place jtds-1.2.5.jar (from jtds-1.2.5 package) in the tomcat 6.0\lib folder
and it works. :]
2011/2/23 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/23/2011 10:29 AM, הילה wrote:
> > I trust the people in the company, but the company's work is with sites
> that
> > any user all over the internet can access. so we want to perform a damage
> > control if some hacker would gain access to our web server, so if he can
> -
> > he won't get access to the DB, at least not with our help of displaying
> the
> > user and password to access the DB :].
>
> I'm curious as to how your webapp can connect to a database without
> credentials.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1lKRwACgkQ9CaO5/Lv0PA9/gCgm7sqTh9ReZ9LXr9gYj9pbYpt
> lIsAni8xXRsB/v/JyQNNSmvkoFI3aUjz
> =15dg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re:[OT] Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/23/2011 10:29 AM, הילה wrote:
> I trust the people in the company, but the company's work is with sites that
> any user all over the internet can access. so we want to perform a damage
> control if some hacker would gain access to our web server, so if he can -
> he won't get access to the DB, at least not with our help of displaying the
> user and password to access the DB :].
I'm curious as to how your webapp can connect to a database without
credentials.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lKRwACgkQ9CaO5/Lv0PA9/gCgm7sqTh9ReZ9LXr9gYj9pbYpt
lIsAni8xXRsB/v/JyQNNSmvkoFI3aUjz
=15dg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
I trust the people in the company, but the company's work is with sites that
any user all over the internet can access. so we want to perform a damage
control if some hacker would gain access to our web server, so if he can -
he won't get access to the DB, at least not with our help of displaying the
user and password to access the DB :].
2011/2/23 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/23/2011 2:06 AM, הילה wrote:
> > I've posted my problem in the sourceforge forums, but no comments have
> > received so far. :(
> >
> > If you have any suggestions to replace this, another way to authenticate
> the
> > tomcat to the DB with user and password that do not appear in clear text,
> > I'll be glad to hear about it.
>
> May I ask what the problem is with cleartext credentials in the
> configuration file? Don't you trust Microsoft Windows file permissions
> and your own administrators?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1lJtgACgkQ9CaO5/Lv0PCj/wCgpM+WD+3V7Pf80Uu7Ys4C81+d
> WokAoLGcwA2jgVeEpgTgKXgOwLgyaut8
> =xFOL
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/23/2011 2:06 AM, הילה wrote:
> I've posted my problem in the sourceforge forums, but no comments have
> received so far. :(
>
> If you have any suggestions to replace this, another way to authenticate the
> tomcat to the DB with user and password that do not appear in clear text,
> I'll be glad to hear about it.
May I ask what the problem is with cleartext credentials in the
configuration file? Don't you trust Microsoft Windows file permissions
and your own administrators?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lJtgACgkQ9CaO5/Lv0PCj/wCgpM+WD+3V7Pf80Uu7Ys4C81+d
WokAoLGcwA2jgVeEpgTgKXgOwLgyaut8
=xFOL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
I've posted my problem in the sourceforge forums, but no comments have
received so far. :(
If you have any suggestions to replace this, another way to authenticate the
tomcat to the DB with user and password that do not appear in clear text,
I'll be glad to hear about it.
Thanks
Hila
2011/2/23 André Warnier <aw...@ice-sa.com>
> הילה wrote:
> ...
>
> The tomcat service (on windows) ran with local system...
>
> Ok, now I get it.
>
> ...
>
> Now the tomcat service is running
>>
> (as a Windows domain user)
>
> and authenticates to the DB with a domain
>
>> user
>>
>
> The above are two entirely distinct matters.
>
> 1) the Tomcat service was running as "LocalSystem", and is now running
> under a Windows Domain user
>
> This does not require any additional components.
> You just need a Domain user, with the appropriate privilege to run a
> Service on this machine, and to set the "logon user" in the service tab of
> the Tomcat service.
>
> It does not require ntlmauth.dll (whatever that is, it is not a part of
> Tomcat), and I would bet that this, by itself, does not create any memory
> leak.
>
> 2) the Tomcat process authenticates to the database using a Windows Domain
> user.
>
> This /does/ require additional components (the jdts-1.2.5.jar in the tomcat
> 6.0\lib folder and the ntlmauth.dll which you mention), which is not
> provided by Tomcat, but apparently here :
>
> http://jtds.sourceforge.net/faq.html
>
> So it looks to me that you should ask the developers of jTDS why you are
> experiencing a memory leak when using it.
> I don't think that Tomcat per se has anything to do with this issue.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
הילה wrote:
...
The tomcat service (on windows) ran with local system...
Ok, now I get it.
...
> Now the tomcat service is running
(as a Windows domain user)
and authenticates to the DB with a domain
> user
The above are two entirely distinct matters.
1) the Tomcat service was running as "LocalSystem", and is now running under a Windows
Domain user
This does not require any additional components.
You just need a Domain user, with the appropriate privilege to run a Service on this
machine, and to set the "logon user" in the service tab of the Tomcat service.
It does not require ntlmauth.dll (whatever that is, it is not a part of Tomcat), and I
would bet that this, by itself, does not create any memory leak.
2) the Tomcat process authenticates to the database using a Windows Domain user.
This /does/ require additional components (the jdts-1.2.5.jar in the tomcat 6.0\lib folder
and the ntlmauth.dll which you mention), which is not provided by Tomcat, but apparently
here :
http://jtds.sourceforge.net/faq.html
So it looks to me that you should ask the developers of jTDS why you are experiencing a
memory leak when using it.
I don't think that Tomcat per se has anything to do with this issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Hey,
When going to tomcat site, you can download "32-bit/64-bit Windows Service
Installer<http://off.co.il/apache/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.exe>
"
That's what I have installed. When installing this, it creates the tomcat
service in windows + the regular folder under c:\program files\apache
software foundation\Tomcat 6.0.
The tomcat service (on windows) ran with local system, and the connection
URL (of the DB) is specified under "c:\program files\apache software
foundation\tomcat 6.0\conf\catalina\localhost\*.xml"
In this xml file, along with the connection URL to DB, there is also the
user name and password of the user that have access to the DB, in clear
text.
In order for me to remove the user and password, I have changed the user
that runs the tomcat service to a domain user with access and permissions to
DB, placed the jdts-1.2.5.jar in the tomcat 6.0\lib folder and the
ntlmauth.dll (which is essential for the windows authentication to work) in
c:\windows\system32.
Now the tomcat service is running and authenticates to the DB with a domain
user (and not SQL user), but I have this memory leak as a side affect which
I'm trying (with, hopefully, the help of you guys) to resolve.
Thanks
Hila
2011/2/23 André Warnier <aw...@ice-sa.com>
>
> Your initial description says :
>
> Until now, we used [b]SQL Authentication[/b] for the tomcat service and
> configuration (user and password for tomcat to access the DB was provided
> within the xml configuration file, under c:\Program Files\Apache Software
> Foundation\Tomcat 6.0\conf\catalina\localhost), but! since we changed
>
> configuration to use [b]Windows Authentication [/b](the user that runs
> tomcat is now a domain user with permissions on the DB + removed user and
> password from xml configuration file), we observed a trend of memory leak,
> where it comes to attention by the process of tomcat, which is increasing
> on
> a daily basis.
>
> This is not very clear to me.
> This all seems to be happening on a Windows platform.
> How exactly then were you previously using "[b]SQL Authentication[/b] for
> the tomcat service" ? Are you talking about the user-id under which the
> Windows Tomcat Service was running ?
>
> (To my knowledge, the only way to run a Service under Windows, is under a
> Windows user-id.)
>
> Or are you talking about the way in which users of the Tomcat applications
> were authenticating to Tomcat ?
>
> If it is this second case, then you must be using some additional component
> to achieve this, because - again to my knowledge -, Tomcat itself does not
> contain components to perform Windows Domain authentication.
>
> Can you enlighten me ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
הילה
(Interesting: my Thunderbird email client seems unable to remove your name above...)
Anyway, hi.
Your initial description says :
Until now, we used [b]SQL Authentication[/b] for the tomcat service and
configuration (user and password for tomcat to access the DB was provided
within the xml configuration file, under c:\Program Files\Apache Software
Foundation\Tomcat 6.0\conf\catalina\localhost), but! since we changed
configuration to use [b]Windows Authentication [/b](the user that runs
tomcat is now a domain user with permissions on the DB + removed user and
password from xml configuration file), we observed a trend of memory leak,
where it comes to attention by the process of tomcat, which is increasing on
a daily basis.
This is not very clear to me.
This all seems to be happening on a Windows platform.
How exactly then were you previously using "[b]SQL Authentication[/b] for the tomcat
service" ? Are you talking about the user-id under which the Windows Tomcat Service was
running ?
(To my knowledge, the only way to run a Service under Windows, is under a Windows user-id.)
Or are you talking about the way in which users of the Tomcat applications were
authenticating to Tomcat ?
If it is this second case, then you must be using some additional component to achieve
this, because - again to my knowledge -, Tomcat itself does not contain components to
perform Windows Domain authentication.
Can you enlighten me ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Bah. The OP replied to me directly (and CC'd the list) and so a REPLY
went to the OP and not to the list. Re-posting back.
On 2/22/2011 4:52 PM, Christopher Schultz wrote:
> הילה,
>
> On 2/22/2011 4:39 PM, הילה wrote:
>> I have used JProfiler to monitor the tomcat process, but haven't found
>> anything useful.
>
> Looking at the types of objects that are taking up all the memory is a
> good place to start. Any obvious memory hogs?
>
>> you can see that the tomcat process is the only one that increasing
>
> If you're using JProfiler, how can you tell if anything /else/ is
> increasing it's memory use? Presumably, Tomcat (and your webapp) are the
> only things running in that JVM.
>
>> it started to happen since i switched to windows authentication.. so I
>> think it's connected?
>
> Has anything else changed? Even something simple like more users? Also,
> can you show us a memory usage graph? If it's not a nice saw-toothed
> graph, then you are likely leaking memory. Try to graph it over 24 hours
> or more -- and remember, this list strips most attachments, so putting
> something online and posting a link to it would be best if you want us
> to see a picture.
>
>> what is a heap analysis? how can i enable and analyze its results?
>
> That's up to the profiler you are using: JProfiler ought to have
> Usually, it means things like looking at what types of objects are using
> lots of memory and which objects are being created en masse and not
> being released.
>
> Poke around in the UI of your profiler to see how you might do that.
>
> -chris
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1lJlUACgkQ9CaO5/Lv0PAF0ACgiC43KVwHwOFCCx9W6bk0qbta
s9YAn1QnUEeZ/PNQDrbNWHJI0TDn8qXc
=y6/B
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Memory Leak in Tomcat
Posted by הילה <hi...@gmail.com>.
Hey,
I have used JProfiler to monitor the tomcat process, but haven't found
anything useful.
you can see that the tomcat process is the only one that increasing, and it
started to happen since i switched to windows authentication.. so I think
it's connected?
what is a heap analysis? how can i enable and analyze its results?
Thanks
Hila
2011/2/22 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> הילה,
>
> On 2/20/2011 8:28 AM, הילה wrote:
> > I work in a company which we use Tomcat (5.5.26 and recently we've
> upgraded
> > it to 6.0.29) to run our application.
>
> Any chance you can move all the way up to 6.0.32?
>
> > since we changed
> > configuration to use [b]Windows Authentication [/b](the user that runs
> > tomcat is now a domain user with permissions on the DB + removed user and
> > password from xml configuration file), we observed a trend of memory
> leak,
> > where it comes to attention by the process of tomcat, which is increasing
> on
> > a daily basis.
>
> Have you done any heap analysis or memory profiling? It's possible that
> the memory leak is not related to the authentication.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1kE6AACgkQ9CaO5/Lv0PAdEACgpRbs3MQv0T4Nfx/r7Jd0HVSA
> nRwAoJ7moo20hj6ioov5sVDepUkdXAjd
> =xTQV
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Memory Leak in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
הילה,
On 2/20/2011 8:28 AM, הילה wrote:
> I work in a company which we use Tomcat (5.5.26 and recently we've upgraded
> it to 6.0.29) to run our application.
Any chance you can move all the way up to 6.0.32?
> since we changed
> configuration to use [b]Windows Authentication [/b](the user that runs
> tomcat is now a domain user with permissions on the DB + removed user and
> password from xml configuration file), we observed a trend of memory leak,
> where it comes to attention by the process of tomcat, which is increasing on
> a daily basis.
Have you done any heap analysis or memory profiling? It's possible that
the memory leak is not related to the authentication.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1kE6AACgkQ9CaO5/Lv0PAdEACgpRbs3MQv0T4Nfx/r7Jd0HVSA
nRwAoJ7moo20hj6ioov5sVDepUkdXAjd
=xTQV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org