Bug #1799990 “tomcat7 doesn't start after upgrade to 7.0.68-1ubu...” : Xenial (16.04) : Bugs : tomcat7 package : Ubuntu

SWick (swick) on 2018-10-25

description:

updated

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-10-25:

#1

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in tomcat7 (Ubuntu):
status:	New → Confirmed

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2018-10-29:

#2

Download full text (3.2 KiB)

The script would usually call tomcat with:
-Djava.security.policy=="$CATALINA_BASE"/work/catalina.policy

The dir here by the suggested sed is replaced by
work -> policy

Many other things are referenced based on "$CATALINA_BASE/..." and they are all in "/var/lib/tomcat7/...".

So is the generated policy file (generated from /etc/tomcat7/policy.d/):
/var/lib/tomcat7/policy/catalina.policy

You said "on upgrade" so I checked some other versions.
There actually is a /var/lib/tomcat[78]/work directory in each installation Trusty to Bionic.

The issue you describe is present in Trusty's version of tomcat7 just as much.

The catalina.sh script in tomcat8 has the bug you describe already fixed, so >=Bionic are good.

I highly appreciate filing this bug and already documenting a way to fix it up in a local installation. But TBH for an SRU I'm afraid to break it for those who fixed their conf e.g. by placing their policy in ..../work and now would suddenly pick up a different config after the update. Post release changes to config handling always suffer from that, and while sometimes negligible, here they might be more severe :-/
There could be some tricks like a postinst checking if the work... path exists and if so keep things as is, but otherwise modify it - but that makes a complex situation more complex.
And /usr/share/tomcat7/bin/catalina.sh is no conffile [1], so users with changes would not be prompted if they had custom changes.

I don't understand why this would hit you "on upgrade" unless you had the same non conffile change in an older version and it is then obviously overwritten on each update (as intended by the packaging).

I wondered what we could do to help further users, but not break those with existing set ups fixed some way.
To enable the security manager you'd switch this to yes [2]:
# Use the Java security manager? (yes/no)
TOMCAT7_SECURITY=no
in /etc/init.d/tomcat7 (there is no other conf file for it that I'd have seen).

If you do so you get your reported effect of a failing start of the process.
Your suggested solution to the (non conffile) catalina.sh would be overwritten every update of the package.
But this:
ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
Would make it work as well, yet should survive upgrades.

We I'd suggest to do in the tomcat7 postinst:
1. if someone already established anything at /var/lib/tomcat7/work/catalina.policy leave it alone
2. if not then create the link as suggested
ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
3. remove the link on "purge" (but don't fail if it doesn't exist)

That should:
1. fix the issue if people just set TOMCAT7_SECURITY=yes
2. not kill users config if there is any at /var/lib/tomcat7/work/catalina.policy
3. not affect configurations that have no set TOMCAT7_SECURITY=yes
4. no be overwritten on upgrades
5. the upgrade to tomcat8 is incompatible anyway and has the fix since release (path in .sh matching real path)

I wonder what your opinion on that is.
If you like the suggestion I might create something for the Team to review.

[1]: https://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-manag...

The script would usually call tomcat with:
  -Djava.security.policy=="$CATALINA_BASE"/work/catalina.policy

The dir here by the suggested sed is replaced by
  work -> policy

Many other things are referenced based on "$CATALINA_BASE/..." and they are all in "/var/lib/tomcat7/...".

So is the generated policy file (generated from /etc/tomcat7/policy.d/):
  /var/lib/tomcat7/policy/catalina.policy

You said "on upgrade" so I checked some other versions.
There actually is a /var/lib/tomcat[78]/work directory in each installation Trusty to Bionic.

The issue you describe is present in Trusty's version of tomcat7 just as much.

The catalina.sh script in tomcat8 has the bug you describe already fixed, so >=Bionic are good.

I highly appreciate filing this bug and already documenting a way to fix it up in a local installation. But TBH for an SRU I'm afraid to break it for those who fixed their conf e.g. by placing their policy in ..../work and now would suddenly pick up a different config after the update. Post release changes to config handling always suffer from that, and while sometimes negligible, here they might be more severe :-/
There could be some tricks like a postinst checking if the work... path exists and if so keep things as is, but otherwise modify it - but that makes a complex situation more complex.
And /usr/share/tomcat7/bin/catalina.sh is no conffile [1], so users with changes would not be prompted if they had custom changes.

I don't understand why this would hit you "on upgrade" unless you had the same non conffile change in an older version and it is then obviously overwritten on each update (as intended by the packaging).

I wondered what we could do to help further users, but not break those with existing set ups fixed some way.
To enable the security manager you'd switch this to yes [2]:
  # Use the Java security manager? (yes/no)
  TOMCAT7_SECURITY=no
in /etc/init.d/tomcat7 (there is no other conf file for it that I'd have seen).

If you do so you get your reported effect of a failing start of the process.
Your suggested solution to the (non conffile) catalina.sh would be overwritten every update of the package.
But this:
  ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
Would make it work as well, yet should survive upgrades.

We I'd suggest to do in the tomcat7 postinst:
1. if someone already established anything at /var/lib/tomcat7/work/catalina.policy leave it alone
2. if not then create the link as suggested
   ln -s /var/lib/tomcat7/policy/catalina.policy /var/lib/tomcat7/work/
3. remove the link on "purge" (but don't fail if it doesn't exist)

That should:
1. fix the issue if people just set TOMCAT7_SECURITY=yes
2. not kill users config if there is any at /var/lib/tomcat7/work/catalina.policy
3. not affect configurations that have no set TOMCAT7_SECURITY=yes
4. no be overwritten on upgrades
5. the upgrade to tomcat8 is incompatible anyway and has the fix since release (path in .sh matching real path)

I wonder what your opinion on that is.
If you like the suggestion I might create something for the Team to review.

[1]: https://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/
[2]: https://git.launchpad.net/ubuntu/+source/tomcat7/tree/debian/README.Debian?h=ubuntu/xenial-devel#n10

Changed in tomcat7 (Ubuntu):
status:	Confirmed → Fix Released
Changed in tomcat7 (Ubuntu Trusty):
status:	New → Confirmed
Changed in tomcat7 (Ubuntu Xenial):
status:	New → Confirmed

Revision history for this message

Marcus Seyffert (mseyffert) wrote on 2018-10-29:

#3

upgrade in this context means: "apt update && apt upgrade", so just a regular security update, not from any older distribution

/etc/init.d/tomcat7 sources /etc/default/tomcat7 (line 111-114) so TOMCAT7_SECURITY is read from their.
The conffile will be created from postinst in tomcat7_7.0.68-1ubuntu0.3_all.deb

If someone installs the last version from xenial-security and activate the security manager with the conffile -> he is getting a broken setup

I've checked the files from the deb-File:

/etc/init.d/tomcat7 creates the policy file at every start
at:
POLICY_CACHE="$CATALINA_BASE/policy/catalina.policy"

but /usr/share/tomcat7/bin/catalina.sh is looking up in the old place ($CATALINA_BASE/work/catalina.policy)

so i think there is no symlink magic necessary. Please patch /etc/init.d/tomcat7 or /usr/share/tomcat7/bin/catalina.sh so booth uses the place.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2018-10-29:

#4

Yeah ok, I see how "apt update && apt upgrade" will strip your workaround from the system.
Thanks for clarifying.

My analysis agrees to everything else.
Thanks for additionally pointing out the sourcing of /etc/default/tomcat7 and most importantly the $POLICY_CACHE at POLICY_CACHE="$CATALINA_BASE/policy/catalina.policy"

Thanks for making me dig even further in that case, I think I have resolved the bits that introduced it now.

I had missed the latter which makes the fix less of a headache.
Let me fetch some other opinions upfront on "symlink to avoid users of working /work/ path" vs "fix in the used path".

I was wondering when between tomcat7 and tomcat8 this was fixed at [1] only to realize that it actually was a delta that introduced the bug.
That leads us to [2] and also the related bug 591802 and [3].

Those read pretty much like the bug here but vice versa.
I wonder if that tomcat6 fix just never made sense in the way it is on tomcat7.

Never the less people might have set things up in a way to make the "$CATALINA_BASE"/work/catalina.policy" path work to get around the issue.

It is worth to mention that in later versions this fx is still carried, juts the paths changed, see [4].

It seems the pathing was changed from "work" to "policy" (but not back to the upstream "conf") as part if this:
      * CVE-2016-1240 follow-up:
        - The previous init.d fix was vulnerable to a race condition that could
          be exploited to make any existing file writable by the tomcat user.
          Thanks to Paul Szabo for the report and the fix.
        - The catalina.policy file generated on startup was affected by a similar
          vulnerability that could be exploited to overwrite any file on the system.
          Thanks to Paul Szabo for the report.

And that made me realize that it might actually have been introduced with the last Xenial security patch. It has:
   7 * SECURITY UPDATE: privilege escalation via insecure init script
   8 - debian/tomcat7.init: don't follow symlinks when handling the
   9 catalina.out file.
  10 - CVE-2016-1240

That change can be seen in [5], but it has none of the follow ups I referred in [4].

Tagging the bug as update regression and assigning Eduardo who worked on the security update. Upgrade regression fixes are usually best with the one who broke it anyway - to consider all other things that made the first change necessary.

[1]: https://github.com/apache/tomcat70/blame/trunk/bin/catalina.sh
[2]: https://git.launchpad.net/ubuntu/+source/tomcat7/tree/debian/patches/0009-Use-java.security.policy-file-in-catalina.sh.patch?h=ubuntu/xenial-devel
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585379
[4]: https://git.launchpad.net/ubuntu/+source/tomcat8/tree/debian/patches/0009-Use-java.security.policy-file-in-catalina.sh.patch?h=ubuntu/bionic-devel
[5]: https://git.launchpad.net/ubuntu/+source/tomcat7/diff/debian/tomcat7.init?h=ubuntu/xenial-devel