Re: CredentialHandler not working for MD5
Mark, On 11/17/23 03:55, Mark Thomas wrote: On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. Is there any reason why SHA-256 is the default? MD5 is the historical default / only implementation for HTTP DIGEST. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Ok thanks. Got it is now working. This step was missing. We didn’t have to do this before. No mention of having to edit Digest inside context.xml here https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html Tried SHA-256, couldn’t get it to work. But MD5 does. Thanks again. This e-mail and any files transmitted with it are the property of Arthrex, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender at 239-643-5553 and delete this message immediately from your computer. Any other use, retention, dissemination forwarding, printing or copying of this e-mail is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, while Arthrex uses virus protection, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
Invoice111708
Please find the attached due invoice, action is required by you. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wondering about tomcat-users.xml could not be found
Christoph,
On 11/17/23 03:55, Christoph Kukulies wrote:
Am 16.11.2023 um 20:12 schrieb Christopher Schultz
What is the user-owner of the JVM process?
root 125216 0.0 0.0 0 0 ? I 09:42 0:00
[kworker/0:0-events]
root 125221 0.0 0.0 0 0 ? I 09:42 0:00
[kworker/0:2]
tomcat 125222 166 9.2 3551824 363244 ? Ssl 09:42 0:16
/usr/lib/jvm/default-java/bin/java
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
-Djava.util.logging.mana
root 125246 0.0 0.0 0 0 ? I 09:42 0:00
[kworker/u4:2-flush-8:0]
Ugh. I *really* hope this is Docker. Add even if it is, /stop running
Tomcat as root/.
Check that all of the above would be both readable and executable by
that user:
ls -ld /var
ls -ld /var/lib
ls -ld /var/lib/tomcat9
ls -ld /var/lib/tomcat9/conf
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /var
drwxr-xr-x 15 root root 4096 Oct 23 16:31 */var*
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /var/lib
drwxr-xr-x 63 root root 4096 Nov 10 10:28 */var/lib*
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld
/var/lib/tomcat9
drwxr-xr-x 6 root root 4096 Nov 17 09:42 */var/lib/tomcat9*
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld
/var/lib/tomcat9/conf
lrwxrwxrwx 1 tomcat tomcat 12 Sep 11 2019 */var/lib/tomcat9/conf*->
*/etc/tomcat9*
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /etc/tomcat9
drwxr-xr-x 4 root root 4096 Nov 16 12:17 */etc/tomcat9*
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config#
Permissions look good, even if the process-owner isn't root.
... and of course that the JVM user can read
/var/lib/tomcat9/conf/tomcat-users.xml which I assume is true since
you said you already checked it.
What is the cwd of the JVM process?
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# pwdx 125222
125222: /var/lib/tomcat9
TIL: pwdx is a thing
Okay, so that all checks out. cwd is /var/lib/tomcat9 and the "allegedly
relative path" is conf/tomcat-users.xml, which points to where the file
actually lives on the disk.
The first message ("reloading") has the full path, and the second
message ("file not found") only mentions a relative path. I wonder if
that is the difference.
Could it be that the second path relates to a missing env-Variable
$CATALINA_BASE or $CATALINA_HOME?
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# cat
/proc/125222/environ | tr '\0' '\n'
USER=tomcat
HOME=/var/lib/tomcat
CATALINA_HOME=/usr/share/tomcat9
CATALINA_TMPDIR=/tmp
JAVA_OPTS=-Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
PWD=/var/lib/tomcat9
JAVA_HOME=/usr/lib/jvm/default-java
> CATALINA_BASE=/var/lib/tomcat9
Well, that all checks out. USER looks weird, but I'm assuming there's a
"sudo java ..." somewhere in the launch command.
It seems the situation is straightened out since I changed the ownership
of the file tomcat-users.xml
-rw-r- 1 tomcat tomcat 2756 Jan 15 2022 tomcat-users.xml
So... who is the owner, now? If the process is really running as "root"
then it should be able to read even file on the filesystem.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CredentialHandler not working for MD5
Mark, On 11/17/23 03:55, Mark Thomas wrote: On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. If you want to default to SHA-256 but fall back to MD5 for clients that don't support DIGEST auth with SHA-256 then you need to next two realms in the LockOut realm. s/next/nest/ One you configure all you users with MD5 passwords and MD5 credential handler. The other you configure all your users with SHA256 passwords and a SHA256 credential handler. i.e. you have two Realms that duplicate the user names but use different digests to calculate the passwords. Peter, while this is entirely technically possible, it's pointless: the purpose in hashing passwords is to protect the stored credentials from being compromised by either the stewards of those credentials (the system administrators) or by some third-party adversary. If you have both MD5 and SHA-256 hashes available on the server, an adversary will ignore the SHA-256 hashes and use the MD5 hashes instead. So if you can guarantee that all your clients support SHA-256, then that's what you should use. Otherwise, you will be stuck with MD5 forever, anyway, so you may as well have a less needlessly-complicated configuration. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wondering about tomcat-users.xml could not be found
> Am 16.11.2023 um 20:19 schrieb l...@kreuser.name:
>
> Hi Chris*,
>
>
>> Am 16.11.2023 um 20:12 schrieb Christopher Schultz
>> :
>>
>> Christoph,
>>
>> On 11/15/23 10:32, Christoph Kukulies wrote:
>>> I'm running tomcat9 under Ubuntu 22.04 with an haproxy 2.8 in front of it.
>>> I'm wondering about the following in the logs:
>>> Nov 15 16:19:23 mail tomcat9[832]: Reloading memory user database
>>> [UserDatabase] from updated source
>>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>>> Nov 15 16:19:23 mail tomcat9[832]: The specified user database
>>> [conf/tomcat-users.xml] could not be found
>>> Nov 15 16:19:33 mail tomcat9[832]: Reloading memory user database
>>> [UserDatabase] from updated source
>>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>>> Nov 15 16:19:33 mail tomcat9[832]: The specified user database
>>> [conf/tomcat-users.xml] could not be found
>>> Nov 15 16:19:43 mail tomcat9[832]: Reloading memory user database
>>> [UserDatabase] from updated source
>>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>>> Nov 15 16:19:43 mail tomcat9[832]: The specified user database
>>> [conf/tomcat-users.xml] could not be found
>>> Nov 15 16:19:53 mail tomcat9[832]: Reloading memory user database
>>> [UserDatabase] from updated source
>>> [file:/var/lib/tomcat9/conf/tomcat-users.xml]
>>> Nov 15 16:19:53 mail tomcat9[832]: The specified user database
>>> [conf/tomcat-users.xml] could not be found
>>> File /var/lib/tomcat9/conf/tomcat-users.xml is definitely there.
>>> It occurs every 10 seconds.
>>> Don't know who is causing this and why. Permissions? Ownership wrong?
>>> -rw-r- 1 root root 2756 Jan 15 2022 tomcat-users.xml
>>> Believe the ownership was wrong. Maybe it came from migrating an old
>>> installation.
>>> What are the correct perms/ownership in /var/lib/tomcat9 and below?
>>
>> What is the user-owner of the JVM process?
root 125216 0.0 0.0 0 0 ?I09:42 0:00
[kworker/0:0-events]
root 125221 0.0 0.0 0 0 ?I09:42 0:00 [kworker/0:2]
tomcat125222 166 9.2 3551824 363244 ? Ssl 09:42 0:16
/usr/lib/jvm/default-java/bin/java
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
-Djava.util.logging.mana
root 125246 0.0 0.0 0 0 ?I09:42 0:00
[kworker/u4:2-flush-8:0]
>>
>> Check that all of the above would be both readable and executable by that
>> user:
>>
>> ls -ld /var
>> ls -ld /var/lib
>> ls -ld /var/lib/tomcat9
>> ls -ld /var/lib/tomcat9/conf
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /var
drwxr-xr-x 15 root root 4096 Oct 23 16:31 /var
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /var/lib
drwxr-xr-x 63 root root 4096 Nov 10 10:28 /var/lib
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /var/lib/tomcat9
drwxr-xr-x 6 root root 4096 Nov 17 09:42 /var/lib/tomcat9
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld
/var/lib/tomcat9/conf
lrwxrwxrwx 1 tomcat tomcat 12 Sep 11 2019 /var/lib/tomcat9/conf -> /etc/tomcat9
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# ls -ld /etc/tomcat9
drwxr-xr-x 4 root root 4096 Nov 16 12:17 /etc/tomcat9
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config#
>>
>> ... and of course that the JVM user can read
>> /var/lib/tomcat9/conf/tomcat-users.xml which I assume is true since you said
>> you already checked it.
>>
>> What is the cwd of the JVM process?
>>
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# pwdx 125222
125222: /var/lib/tomcat9
>> The first message ("reloading") has the full path, and the second message
>> ("file not found") only mentions a relative path. I wonder if that is the
>> difference.
>>
>
>
> Could it be that the second path relates to a missing env-Variable
> $CATALINA_BASE or $CATALINA_HOME?
>
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config# cat
/proc/125222/environ | tr '\0' '\n'
USER=tomcat
HOME=/var/lib/tomcat
OLDPWD=/
CATALINA_HOME=/usr/share/tomcat9
SYSTEMD_EXEC_PID=125222
LOGNAME=tomcat
JOURNAL_STREAM=8:1778827
CACHE_DIRECTORY=/var/cache/tomcat9
JDK_JAVA_OPTIONS= --add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
CATALINA_TMPDIR=/tmp
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
INVOCATION_ID=84b60xxxa420e09ed
JAVA_OPTS=-Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
LANG=en_US.UTF-8
PWD=/var/lib/tomcat9
JAVA_HOME=/usr/lib/jvm/default-java
CATALINA_BASE=/var/lib/tomcat9
root@mail:/var/lib/tomcat9/webapps/ROOT/WEB-INF/config#
> Peter
It seems the situation is straightened out since I changed the ownership of the
file
Re: CredentialHandler not working for MD5
On 16/11/2023 18:06, Peter Otto wrote: 1. Configure BASIC auth with clear-text passwords in the Realm and get that working. 2. Switch to DIGEST auth with clear-text passwords in the Realm and get that working. 3. Then configure DIGEST auth and digested passwords in the Realm. Hi Chris, Step 1 & 2 work Step 3 will not work with the clear txt password, only the digested password, which means the text password in tomcat-users.xml. In past versions of Tomcat, the clear text password would work. Testing with the manager application. Step 1: Use the following user in tomcat-users.xml Step 2: Edit $CATALINA_BASE/webapps/manager/WEB-INF/web.xml BASIC changed to DIGEST Step 3: Edit $CATALINA_BASE/webapps/manager/META-INF/context.xml to specify MD5 digest (rather than default of SHA-256) ... Modify Realm configuration in server.xml Calculate password value for tomcat-users.xml digest.sh -a MD5 -s 0 \"both:Tomcat Manager Application:tomcat\" both:Tomcat Manager Application:tomcat:802b9260bb5c0837169f99e64aca2fd0 Update tomcat-users.xml roles="manager-gui"/> As expected, this works. I will note it took me a couple of attempts to get right as I had some typos in my configuration. If you use the default digest of SHA-256 then you don't need to configure the DigestAuthenticator in the content.xml file. If you want to default to SHA-256 but fall back to MD5 for clients that don't support DIGEST auth with SHA-256 then you need to next two realms in the LockOut realm. One you configure all you users with MD5 passwords and MD5 credential handler. The other you configure all your users with SHA256 passwords and a SHA256 credential handler. i.e. you have two Realms that duplicate the user names but use different digests to calculate the passwords. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Wondering about tomcat-users.xml could not be found
Hi, > I'm running tomcat9 under Ubuntu 22.04 with an haproxy 2.8 in front of it. > > I'm wondering about the following in the logs: > > Nov 15 16:19:23 mail tomcat9[832]: Reloading memory user database > [UserDatabase] from updated source > [file:/var/lib/tomcat9/conf/tomcat-users.xml] > Nov 15 16:19:23 mail tomcat9[832]: The specified user database > [conf/tomcat-users.xml] could not be found > Nov 15 16:19:33 mail tomcat9[832]: Reloading memory user database > [UserDatabase] from updated source > [file:/var/lib/tomcat9/conf/tomcat-users.xml] > Nov 15 16:19:33 mail tomcat9[832]: The specified user database > [conf/tomcat-users.xml] could not be found > Nov 15 16:19:43 mail tomcat9[832]: Reloading memory user database > [UserDatabase] from updated source > [file:/var/lib/tomcat9/conf/tomcat-users.xml] > Nov 15 16:19:43 mail tomcat9[832]: The specified user database > [conf/tomcat-users.xml] could not be found > Nov 15 16:19:53 mail tomcat9[832]: Reloading memory user database > [UserDatabase] from updated source > [file:/var/lib/tomcat9/conf/tomcat-users.xml] > Nov 15 16:19:53 mail tomcat9[832]: The specified user database > [conf/tomcat-users.xml] could not be found > > > > File /var/lib/tomcat9/conf/tomcat-users.xml is definitely there. > > It occurs every 10 seconds. > > Don't know who is causing this and why. Permissions? Ownership wrong? > > -rw-r- 1 root root 2756 Jan 15 2022 tomcat-users.xml Is your Tomcat running as root? I hope not, but if it's running as user tomcat or some other unprivileged user, it won't be able to read your tomcat-users.xml as long as the user is not member of group root. Regards, Simon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8: Random 404 and 505 errors
On 16/11/2023 22:53, Pavan Veginati wrote: Hi, We are seeing random 404 and 505 errors with GET and POST requests. Out of the 10 million daily requests in one cluster, there are 2-3 such 404 errors. In another cluster with around 100 million daily requests, we are seeing 20-30 404s on average per day. Requests with a 505 error are rare and only happen once or twice a week. The same requests were successful a few milliseconds before and after the error. The servlet that handles these requests always returns a 200 with an appropriate error response if it fails, but never a 404. So, it is surprising to see a 404 response. Hmm. Tomcat returns a 505 response in a single location. It does this when it doesn't understand the HTTP version that has been received in the request line. Assuming the clients aren't sending malformed HTTP requests that suggests the input buffer is getting corrupted. That form of request mix-up is rare but has happened due to both Tomcat bugs and application bugs in the past. I don't think there are any fixes since 8.5.88 that relate to this but it would be worth considering updating to 8.5.96. Do you use any of: - WebSocket - Servlet asynchronous API - Sendfile - HTTP/2 I'm just trying to narrow down the areas of code we may need to look at. I think the 505s offer the best opportunity to track this down as they only happen in one place and debug logging is available. We've only had this issue in our test environment (similar to prod) a couple of times, but we can't reproduce it again. I've found a similar issue reported here: https://lists.apache.org/thread/rxypsggr36joq8fcd44khjky9w4qf4xx Deployment Details: Tomcat Version: 8.5.88. Built from source. Java Version: JDK 17. Network Topology: Direct server to server internal calls with no load balancers in between. Are there any known issues that could be causing this, No. and are there any specific logs we can enable that might help us debug this issue further ? Enable debug logging for the Http11Processor. Add this to logging.properties: org.apache.coyote.http11.Http11Processor.level=FINE That will log additional detail for most failed requests (but not 404s). Add %r in the access log pattern which will log the entire request line for every request. For each 404, check the access log and see whether the request line is as expected. For each 505, check both the access log and the standard log files. If you can provide us with the request lines from the access log for each 404 (along with whether or not they are as you expect) and the request line and debug log entry for each 505 we will hopefully be able draw some further conclusions. Given you are building from source, one possible investigative option is providing you with a custom patch that adds additional debug logging. If we reach the point where that would be helpful, is that something you'd consider? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
