On Fri, Jun 2, 2017 at 4:41 PM, Mark Thomas <ma...@apache.org> wrote: > On 02/06/2017 21:29, Christopher Schultz wrote: >> Coty, >> >> On 6/2/17 2:15 PM, Coty Sutherland wrote: >>> Hi, >> >>> I'm sure this has been brought up before, but I can't find it so I >>> figured I'd ask... >> >>> A vanilla installation of tomcat fails to start the admin webapps >>> with the Security Manager enabled. This is because the manager and >>> host-manager webapps ship with a context.xml. >> >> Why is that a problem? >> >> (I'm honestly asking... I've never looked much into the details of how >> Tomcat + SM works.) > > If a SecurityManager is enabled, any META-INF/context.xml is ignored > since that file can be used by bypass some of the constraints imposed by > the SecurityManager. > > >>> The behavior isn't documented anywhere that I see, so I'm curious >>> if it's intentional or has been flying under the radar. > > It is known and it hasn't been changed so I guess that makes it intentional. > >>> Are there >>> reasons why we would not trust an application that we ship when >>> running under the Security Manager? > > No. But the 'don't use META-INF/context.xml' rule is a general one, not > a per application one. > >>> Is there a reason we can't >>> move the context.xml for each app into the appropriate >>> conf/[Engine]/[Host] directory to fix this? >> >> We probably can, but that makes the app(s) a little less >> trivially-relocatable. > > It would be better if they were self-contained. It is easier for folks > to remove them.
I was going to suggest copying them into conf or using a symlink, but copying them breaks tomcat when they are removed from webapps and a symlink causes an NPE in o.a.c.startup.HostConfig.deployDescriptor(). I guess we should leave it up to the user to decide and maybe document it somewhere a bit more clearly? > A better solution would be to switch to the corresponding filter. > >>> If you guys think this is a bug I can file a BZ and fix it :D Or, >>> mark it as "Beginner" since it's trivial. > > Enhancement request to switch to the filter works for me. The fix is > still fairly trivial in with that solution. Filter? Did I miss something? This email and the BZ that I filed about the filter attribute are two separate things. > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
