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