Mark,
On 25.11.2013 11:08, Mark Thomas wrote:
Unrelated to this issue, I have recently expanded the section of the
docs that covers securing the default applications. The updates will be
in the next release. Until then you can read it via the copy of the docs
built by the CI system:
http://ci.apache.org/projects/tomcat/tomcat8/docs/security-howto.html#Default_web_applications
On a related matter, if one configure file permissions as recommended here:
http://tomcat.apache.org/tomcat-8.0-doc/security-howto.html#Non-Tomcat_settings
Manager application will be unusable for deployment by uploading .war
files. Automatic war unpacking also won't work. What is the best
practice for remote deployment of .war files in such environment?
I usually copy .war file to temporary dir on server using scp client.
Then, using ssh client I extract the .war file, chown .war file and
extracted folder, and mv .war file and extracted folder to webapps/. I
then wait for auto deployer to pick them up. Is there a better
alternative to that?
The one question this raises for me is should the Manager application be
limited to localhost be default? I'd be interested in the community's
views on that.
Yes. A lot of Tomcat instances I've seen run under user root.
Unfortunately, a lot of users needs Tomcat running on port 80, and they
don't have time or knowledge to configure jsvc or httpd. They
unfortunately resort to running tomcat as root, forgetting that manager
application (and all other deployed webapps) will also have root
privileges. So, adding one more level of security by enabling
RemoteAddrValve will help security ignorant users, and will take only
little additional effort for admins.
I also think it would be very usefull if 401 error page for manager
application does not example password "s3cret", but randomly generated
long password unique for every request. I guess there is a number of
Tomcat instances out there with username "tomcat" and passoword
"s3cret", and that needs to be prevented.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
