Bug#919638: solr-tomcat: Permission problems after update to tomcat9

[Markus Koschany]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20190226/273869ad/attachment.sig>