Bug#845385: Privilege escalation via removal

[Emmanuel Bourg]

Le 30/11/2016 à 00:20, Markus Koschany a écrit :

> rm -rf /etc/tomcat8
> 
> I mean purge means purge. Remove all files, don't leave anything behind.

That's tempting but I wonder if we aren't missing something.

Other packages are installing things under /etc/tomcat8, for example
solr-tomcat and jspwiki, but fortunately in these cases the packages are
installing symlinks to other configuration files, and by the time
tomcat8 is purged these links have already been removed.

Is there another case where removing the files in /etc/tomcat8 is
undesirable? What about files created by the sysadmin in this directory
(like the ones we avoided to chmod on upgrades in #825786) ?


> As another improvement suggestion for Tomcat 9, we could stop deleting
> the tomcat user on purge and let the admin decide. I believe this is
> even consensus within the project and will protect against reusing files
> with the old GID and UID for something unintended.

I thought the users created by a package were supposed to be removed
when the package is purged, but this isn't a requirement in the policy.
I've found #621833 that deals with this topic and the consensus is
indeed not to remove the user.

If we follow the consensus I would also suggest reusing the same user
when switching to a new version to Tomcat. The last time I switched from
tomcat7 to tomcat8 it was annoying to chmod manually the log files of my
web applications. If there was a unique tomcat user for the
tomcat{7,8,9} package that would be easier.

This would be similar to the jetty8 and jetty9 packages sharing the same
'jetty' user (but in this case the user is also removed when the package
is uninstalled, this is problematic when the old package is removed
after the new one is installed).

Emmanuel Bourg