Tomcat configuration weirdness

[Brian Pendell]

So let's start with the specifics:
Tomcat 7.0.22
Windows 7 64-bit
All operations being performed with administrator privileges by the same user.
NOT using Eclipse or any other development environment. This is just Tomcat and a text file editor.

What happens: I am preparing a web application which uses Tomcat as the container to run it. So Tomcat installation is performed as part of the overall install.

As part of the install, we 1) Install Tomcat but do NOT activate the service. 2) Automatically copy over custom server.xml and tomcat-users.xml into the conf\ directory, replacing those automatically generated by Tomcat during installation. 3) NOW start Tomcat.

The new files switch the userdatabaserealm over to an MD5 digest from clear text, change the SSL port from 8443 to something else, define three new roles , and several users which have these roles.

What could possibly go wrong?

Well, the problem is that when I attempt to log into the application using the roles (the app's web.xml has these roles defined in it, and restricts access to some pages), I get error 401: Access denied.

I am a little puzzled by this. I know that the server.xml is being correctly read, because HTTPS responds on the new port, not on 8443. And I know tthat the tomcat-user is defined, because if I enter the user name and a deliberately incorrect password, the prompt tells us to try again. But when I enter the user name and the correct password, it goes directly to error 401.

Now, here's the strange thing: I CAN get this to work.

How? Simple. Cut the user names and roles out of tomcat-user.xml, save the file, paste them back in, save the file. Restart Tomcat. Presto, suddenly it works.

Well, okay, one time this DIDN'T work. I was forced to reinstall Tomcat from scratch and make the appropriate changes by hand to both tomcat-users.xml and server.xml. And then it worked.

So I can get the system working, but any good installation package should work properly out of the box, without needing me to cut lines out of the file, then paste them back in.

So what is happening here?

Is there some kind of security feature that prevents files from being copy/pasted?
Is it a permissions issue of some kind? It shouldn't be, because the user performing the operations has administrator privileges, but I can't rule it out.
Is it something to do with the timestamp?
Is Tomcat caching this information somehow? If so, can it be disabled?

Is this a problem that will disappear by upgrading to Tomcat 7.0.52? What about Tomcat 8?

Respectfully,

Brian P.

[Tim Holloway]

I don't recommend running Tomcat as a privileged user. It can provide a way for outside exploits to come in through the Internet and eat your machine.

As to what it wrong with your security setup, it's hard to tell. There are some considerations, however.

First, security for webapps under Tomcat that use the J2EE standard security is managed by Realms. You can define a Realm for a single webapp or for all webapps in the container. The Realm itself is a plug-in component, and there are Realm modules for file-based credentials (tomcat-users.xml), database, LDAP, single-signon and more.

There was originally only one Realm that actually used the tomcat-users.xml file and that was the MemoryRealm. It really wasn't suitable for production use, since the tomcat-users.xml file was read at server startup and never read again. So you had to restart Tomcat in order to get new users or roles to be seen. Recent versions of Tomcat include 1 or 2 new Realms that use tomcat-users.xml but can see on-the-fly changes to it.

Regardless, changes in the user roles made while a user is logged in do not take effect while that user is logged in, not for any Realm. This is for security reasons, since you would otherwise be changing the wheels while the car is driving and potentially creating temporary security loopholes.

When you stop tomcat and restart it, it is possible that session information could be cached and restored when tomcat comes back up, so any time you're making changes to the web apps or security configuration and restarting Tomcat, it's a good idea to delete the files and directories under Tomcat's work and temp directories.

Also, note that when you have 2 WARs with the same name in the Tomcat webapps directory (for example, abc.war and an abc directory in exploded WAR format), that the exploded WAR will be the one used, even if the war file is newer.

[Brian Pendell]

Hello, Tim, thanks for the response.

Regardless, changes in the user roles made while a user is logged in do not take effect while that user is logged in, not for any Realm. This is for security reasons, since you would otherwise be changing the wheels while the car is driving and potentially creating temporary security loopholes.

Well, yes, but these changes are made before ANY user is logged in. This all happens at installation before Tomcat is even turned on.

Also, note that when you have 2 WARs with the same name in the Tomcat webapps directory (for example, abc.war and an abc directory in exploded WAR format), that the exploded WAR will be the one used, even if the war file is newer.

Noted. However, this is not an issue. I place the .war file in webapps at installation, and it then explodes the .war file and uses the directory structure created from same. Since the two are exactly the same, discrepancies between them are not an issue, at least not on installation.

When you stop tomcat and restart it, it is possible that session information could be cached and restored when tomcat comes back up, so any time you're making changes to the web apps or security configuration and restarting Tomcat, it's a good idea to delete the files and directories under Tomcat's work and temp directories.

Okay.

So here is what I did this morning.
1) Shut down tomcat.
2) Backed up my existing tomcat-users.xml and server.xml.
3) Copied over some old copies of tomcat-users.xml and server.xml from my installer directory into TOMCAT-HOME. These were dated quite some time ago, but the content is almost identical.
4) Started tomcat and attempted to log in. Got error 403.
5) Used touch on both files and restarted. Shut down browser completely and attempted login. Still error 403.
6) Shut down tomcat. Deleted tomcat's \temp and \work directories. Restarted. Shut down browser completely and attempted login. Still error 403.

7) Restored the .xml files backed up in 2). Suddenly it starts working again.

It's almost as if Tomcat somehow tracks the original files and will start throwing error 403 if they are changed.

The realm being used is <Realm className="org.apache.catalina.realm.UserDatabaseRealm">

It may be I do not HAVE to restart tomcat when I make changes to these files, but I do so anyway. Learned reflex from MemoryRealm.

So as you can see, the puzzle is not yet solved. But thanks for your effort so far.

Respectfully,

Brian P.

[Brian Pendell]

Okay, I think I've solved it. It turns out I had to modify a setting in server.xml -- this was in the new file but wasn't in the old version I was copying over.


This did not work:

<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" digest="md5" />


This DID work:

<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" digest="md5" />
</Realm>


So I had to add "LockOutRealm" to server.xml in order to not get the error 403. Before that, I would get that error even when the roles and passwords were correct. Once added, I was able to get in.

I'll leave this open for a few days so people can comment on what happened, but the issue does appear to be resolved. I'm going to read up on LockOutRealm and associated Tomcat technology. Any comments that might prove enlightening are welcome.

Respectfully,

Brian P.