Bug#825786: tomcat8: postinst script overwrites file permissions in /etc

[Markus Koschany]

On 27.07.2016 11:55, Emmanuel Bourg wrote:
> Le 22/07/2016 à 23:18, Markus Koschany a écrit :
> 
>> I would like to go ahead with this solution in unstable. I don't think
>> that changing the permissions in /etc/tomcat8/policy.d (security
>> manager) to root:root will have a negative effect, on the contrary.
>> Those rules should only be modifiable by the system administrator anyway.
> 
> Currently the files in /etc/tomcat8/policy.d are owned by root:tomcat8
> with 644 permissions. Only the administrator can modify them, so
> switching to root:root will not change anything.

The update is necessary because the current postinst script overwrites
permissions for all files under /etc/tomcat8 unconditionally to
root:tomcat8. Already installed setups are unaffected by my proposed
change by the way. New setups will certainly benefit from it by using
default Debian values. Since no special permissions are required
deviating from the default is neither sensible nor necessary in my opinion.

>> Regarding /etc/tomcat8/Catalina I couldn't find any information that
>> indicate a necessity for write access to this directory. It would also
>> be wrong if a process wrote to /etc because all files in /etc should be
>> static according to the FHS.
> 
> The Catalina directory is used to store the context.xml files from the
> deployed webapps. See:
> 
> https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Defining_a_context
> 
> "Individual Context elements may be explicitly defined: In an
> individual file at /META-INF/context.xml inside the application files.
> Optionally (based on the Host's copyXML attribute) this may be copied
> to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
> application's base file name plus a ".xml" extension."
> 
> I agree this feature isn't FHS compliant but I can't see a better
> alternative for now. If we were to change that I'd prefer doing it in
> the new tomcat9 package to avoid disrupting existing installations.

I'm strongly in favor of changing this behavior pre Stretch because
Tomcat 8 will be supported for several years to come. If it is done
right, there won't be any disruptions. The question is whether the
tomcat8 users needs to write to this directory *at runtime* or if it is
acceptable that the administrator will be the only one who is able to
modify the context.xml file. Write operations from Tomcat 8 to
/etc/tomcat/Catalina/ would be just wrong.

Besides the documentation mentions $CATALINA_BASE/conf/context.xml and
that would be in /var/lib/tomcat8/conf which currently is a symlink to
/etc/tomcat8/. So in this case, mapped to the Debian layout, they are
talking about /etc/tomcat8/context.xml. According to the docs another
option would be
$CATALINA_BASE/conf/[enginename]/[hostname]/context.xml.default

Now I wonder what /etc/tomcat8/Catalina is really used for.

So the question is

does Tomcat 7/8 need write access to the conf directory at runtime and
if yes why?


>> I would also update the Tomcat7 package.
> 
> Since we are going to remove tomcat7 I don't think it's worth updating it.

I would agree with you if you were not the one who also insisted that
this bug should be fixed in unstable first. I really want a solution for
Tomcat 7 too because it is supported in Wheezy and Jessie and at the
moment I'm not convinced that overriding the permissions for all files
under /etc/tomcat{7,8} is something that can't be avoided and can only
be fixed in Tomcat 9.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20160727/676a10f6/attachment.sig>