Am 26.02.19 um 09:46 schrieb Emmanuel Bourg: > Control: reopen -1 > Control: notfixed -1 9.0.16-2 > > Le 17/02/2019 à 12:38, Markus Koschany a écrit : > >> Thank you for the confirmation. Then I think reassigning this issue to >> src:tomcat9 and fixing it there is sensible. > > Unfortunately the modification broke tomcat9 installations when solr > isn't installed (#923299) and I had to revert it in the version 9.0.16-3.
Sorry, I didn't expected that behavior from systemd. > We have to figure out another solution. Either: > 1. abandon the idea of restricting tomcat9 write access > 2. change solr-tomcat so that it modifies the tomcat9 permissions on install > 3. drop solr-tomcat, upstream recommends using Jetty after all. I personally like the sandboxing idea of tomcat9 which improves the overall security of the server. We should keep the current settings. Making one package modify the files of another package is tricky and I bet there are thousand Debian Policy rules to follow. We don't need to drop solr-tomcat either for this release cycle because apart from this permission problem everything else seems to work. This will be the last time solr-tomcat is part of a stable distribution though. The latest solr versions embed Jetty and solr is no longer a web application but a standalone server. Still the best way to fix this bug is to add /var/lib/solr to the sandbox if the directory exists. There must be some kind of conditional solution for systemd service files so that the option is only processed if another condition is true. Tomcat 9 could also simply create /var/lib/solr which would also address this problem.
signature.asc
Description: OpenPGP digital signature