Bug#821391: tomcat7-admin: Patch 7.0.28+deb-u4 overwrite owner of all /etc/tomcat7

[David_dev Dev]

Hi,
Thx for the answer.

the jmxremote.password 600 mode is a mandatory from Tomcat configuration.
Is set to another mode tomcat will not start.
It's the same as the ~/.ssh/id_rsa configuration.

Some corrections on the following answer :
- the script chown root:tomcat7 (and not root:root).

I found the explanation of why for this choice by debian currently :

# configuration files should not be modifiable by tomcat7 user, as this can
be a security issue

        # (an attacker may insert code in a webapp and have access to all
tomcat configuration)

        # but those files should be readable by tomcat7, so we set the
group to tomcat7

        chown -Rh root:$TOMCAT7_GROUP /etc/tomcat7/*


Note that tomcat7 is launched by default by a tomcat7 user in debian
package (a good choice ! better than root :) )



- the home of tomcat7 : wow i even don't see that configuration. Don't
known if it's a standard rule for debian application account ? not enough
knowledge of debian for that, but seem not be a problem.


- for the package, after reading a little more, i'm not sure the scrit
postinst is linked to tomcat-admin, but more to a core tomcat7.
tomcat7-admin seem to add only admin webapps for managing the tomcat. but
don't know how to find in which package the script come from.


And last, sorry for english, not my native langage :)


*** Some links about jmx config from most "official" site. I'm very
interesting by a debian doc about thisbut not seen with a quick search.


https://db.apache.org/derby/docs/10.9/adminguide/radminjmxenablepwd.html : "The
file must be readable by the owner only. Also, you may need to change the
permissions on the password file to be readable only by the user who starts
the server."


http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html

see chapter  "Using File-Based Password Authentication"


http://www.ibm.com/support/knowledgecenter/SSCP65_5.0.1/com.ibm.jazz.repository.web.admin.doc/topics/t_server_mon_tomcat_option2.html
(in french) :

"Important : Etant donné que des mots de passe en texte en clair sont
stockés dans le fichier jmxremote.password, ce fichier doit être lisible
par le propriétaire uniquement. Sinon, le programme se ferme avec une
erreur."

--> ~ "the file must be read only by the owner of tomcat or the application
will be closed with error"



---

Another thought maybe : if a security patch needs to reinit some rights in
the tomcat7 conf folder, maybe the deb package system could modify only
files known by him and not user custom files ? like when a user modify a
conf, the deb package system ask the user to take the new debian one, keep
it's file or merge the 2 files ...


Maybe a possibilty to do the same like asking if modify all filles or only
files from debian (+ recommand to check the other file rights !)


David CHALON



2016-04-19 9:00 GMT+02:00 Markus Koschany <apo at debian.org>:

> Am 18.04.2016 um 13:55 schrieb David CHALON:
> > Package: tomcat7-admin
> > Version: 7.0.28-4+deb7u4
> > Severity: important
> >
> > Dear Maintainer,
> > *** Please consider answering these questions, where appropriate ***
> >
> >    * What led up to the situation?
> >       All tomcat servers crash after the auto update via
> unattended-upgrade
> >    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> >       Correct manually our specific owner files and restart tomcat7
> service
> >    * What was the outcome of this action?
> >       Impossible to start all the tomcat7 services (with JMX  configured)
> >    * What outcome did you expect instead?
> >       that the patch don't modify files that don't come from the package.
> >
> > Details :
> >       We use a tomcat7 debian installation.
> >       We modify to use tomcat7:tomcat7 user for the tomcat7 processes
> >       we want to add JMX access configuration with user/password access
> -> no debian doc found => configuration taken from "official" oracle
> documentation.
> >               => put jmxremote.user and jmxremote.password in
> /etc/tomcat7 (symlinked to /var/lib/tomcat7/conf for official oracle path
> conservation)
> >               => mandatory kmxremote.password = right 600 on the file
> and then we chown tomcat7:tomcat7 the file too.
> >
> >       We use unattended-upgrade for security patch. This morning ->
> deploying some tomcat7  patch on all serveurs.
> >       -> In the tomcat7.postinst there is chown -Rh root:(GROUP) on
> /etc/tomcat7 !
> >       => jmxremote.password misconfigured and tomcat7 don't start...
> >
> > Ideas or solutions :
> >       Modify only files coming from the package.
> >       Or interesting on how debian want we configure the JMX access, as
> if we take official recommandation it leads to a fatal crash.
>
>
> Hello,
>
> thank your for the report. The behavior you noticed is currently
> intended but I wonder if we should continue to overwrite the standard
> permissions (root:root) in /etc/tomcat{6,7,8} in the future. I'm not
> sure if you really need to use 600 permissions on that file. Did you try
> to remove the r flag with chmod o-r and keep Debian's standard
> permissions of root:tomcat7 instead? That would also restrict read
> access for other users but the tomcat7 user could still read the file
> because it is also in group tomcat7.
>
> We have to investigate this issue more thoroughly though because it
> affects all Tomcat versions in Debian. I also find it strange that the
> home directory of user tomcat7 is /usr/share/tomcat7 instead of
> /var/lib/tomcat7. In /usr/share should never be a home directory in my
> opinion.
>
> Regards,
>
> Markus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20160419/eaaa9b8d/attachment-0001.html>