Le 29/07/2016 à 11:20, Markus Koschany a écrit : > If we keep root:tomcat8 then I think 640 is sensible and appropriate.
There is a downside though, our package will become unusable with the IDEs since local users will no longer be able to read the configuration. I don't think we can satisfy both use cases (production server and local development server) with a single configuration. Securing the default configuration is more important, so we may have to add an extra CATALINA_BASE directory somewhere under /var/lib suitable for developers (maybe in tomcat8-user?). > 1. Do not override file permissions for custom files in /etc/tomcat8 any > longer. Be explicit instead and only change them for known Debian files. Good. The script no longer checks the existence of the files, I suspect this may break if tomcat-users.xml is removed by the user for example. For the policy.d we can chmod the whole directory, no need to whitelist the files. > 2. Make /var/lib/tomcat8/conf a real directory and remove the symlink. > Instead symlink all Debian files from /etc/tomcat8 into > /var/lib/tomcat8/conf > > 3. Remove /etc/tomcat8/Catalina and move it into > /var/lib/tomcat8/conf/Catalina I'm not fond of this change, this is more complicated and will break the expectation that files added to /etc/tomcat8/ are automatically seen as part of the Tomcat conf directory. This may break existing installations, for example when a SSL connector references a keystore relatively to the CATALINA_BASE directory. Currently I have something like this on my servers: <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="conf/keystore.p12" keystorePass="secret" keystoreType="PKCS12"/> Here the keystore.p12 file is located in /etc/tomcat8 and automatically available at /var/lib/tomcat8/conf/keystore.p12. With the proposed changes the server.xml file will have to be updated with an absolute path. If we were to implement this I think it should happen in the next tomcat9 package instead. > The stable patch only implements point 1 that should address the issue > described in this bug report. Ok, the stable patch shouldn't change the permissions to 640 though.