tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <>
Subject Re: Policy files
Date Thu, 25 Apr 2013 03:25:32 GMT
Well I understand that there is only one SecurityManager per JVM, but as 
you mentioned I can restrict actions for specific CodeBases. This is 
what I am actually trying to do. I want the student web applications to 
have only a hand full of permissions defined in a policy file. I think I 
explained my self wrong earlier. The policy file I am speaking of, the 
one I want to apply to student projects, is more like a set of 
permissions that I want to give the web applications. I mainly want my 
testsuite and everything packaged with it to have all permissions.  
Generally the student projects should have no permissions. I want to 
give these applications only a minimal set of permissions, only the ones 
they actually would need to fullfil their tasks.

The WebappClassLoader supports the method addPermission(Permission) 
which is nice somehow, but I don't want to hard code the permissions but 
rather have them in a policy file or so. The reason for having the 
permissions in a policy file is mainly because I thought I can configure 
something in context.xml so that the policy file gets picked up by tomcat.

I just don't want to have these applications running on my computer not 
knowing what they actually do. To be honest I couldn't think of any 
permission I would give a student application. The libraries that can be 
used are predefined, so I give these jar files the permissions for 
reflection or whatever they need to work properly.

Am I simplifying the whole thing and is what I want much harder to 
achive than I think?

Am 24.04.2013 22:20, schrieb Christopher Schultz:
> Hash: SHA256
> Christian,
> On 4/24/13 1:51 PM, Christian Beikov wrote:
>> Yes we are talking about security manager policies.
> Good :)
> There's a lot about Spring that I don't know about, so I was just
> checking that you weren't talking about some crazy IoC thing or
> annotation-driven magic that no mere mortal can follow.
>> So there is no possibility to just push the policy file to the
>> WebappClassLoader?
> Nope: the SecurityManager applies to the whole JVM. But, the policy
> can bless certain JARs, etc. as being privileged. So, you make Tomcat
> and whatever code you wrote privileged and then leave all the student
> code to run under the heavy-handed security policy.
>> As stated in the reply to Matrin Gainty there do exist methods to
>> restrict the webapp, but unfortunately no method for supplying a
>> policy file.
> Right: you can control the deployment descriptor(s) but not really
> much else.
>> So this means I have to parse the policy file myself and add the
>> permissions manually to the classloader?
> Uh... I don't think that's possible. I must admit I'm no ClassLoader
> ninja, but I don't think there's a way to tell a ClassLoader anything
> about security policies.
> What kinds of operations are you trying to restrict?
>> Are there any options in the context.xml I could set for specifying
>> a webapp local policy so that I don't have to fiddle around with
>> how tomcat is called? I know how to apply a policy at runtime, but
>> don't know how this affects tomcat when I apply it e.g. in a
>> ServletContextListener.
> I think I'd have to understand more about what you are trying to do in
> order to be helpful. The SecurityManager applies its policies globally
> and you can't customize anything on a per-ClassLoader basis. You can
> do it on a per-codebase basis, but you have to know the URL(s) of the
> codebase(s) in advance.
>> Would be cool if there was an option to do that kind of stuff.
> Yes, I rather think it would be cool to specify a security policy on a
> per-ClassLoader basis, but there are definitely some thorny issues
> there otherwise I think Sun/Oracle would have implemented that
> capability by now.
> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> Jd5sNOisQ9mdVowygJAwppYDqtUalmMZ5qZTtsyYZYWKn3QpiML10Qr36elFZsA5
> zoCA1JRB+hwC/vhNgJGdhhNxDOEQo66mfiJlfQ0rHpOGwVrGppAuSV4kVfX5aZCQ
> 9Ssq2HZvfLE7tL0pg+qnBT1AA9/HU+hAmk4GkCETSMR16jB8NrwI10ejU7gt1F4F
> BaUCULZvYtLRelbsAQTfz4ZOQL0FZq2zD85BeZ+hey0koinpr+nY1aRGy4ASbmrM
> Eke8ruYKW5xbVmSyQ0A4JmaYmMrYFfc7SgdR7UOkD21wbHA87fSHF9oNhhom2Tqd
> Qsdn89swuBwp6XkS1akbfRc6RJ4WPCxNfxBWceGWlJewtgY8XRD8lPYOsHCSiVN/
> SOSVnmCaa8Fs6ygk75wo6IKI+VlLRJqFSK5pr1iGK9hVC+xgBGB5APrhMhvSCUmO
> SuP6IxFMSRDhghlxUbDhd7hW7KZnpXGQCJZjSoEsW/ysjhwy0hfhLbkEGTyYV8Az
> wCap5r3eHc5KsHP0FK9F283DbiUhV8oHoLK0ddzKd9KrHbxap4Vekk2tqbUA52Vn
> gpcRk5vodI88w0mvtdc9b57luHPedmY87bqmayjqzh6VHixlT/O8+CQhmJLRrln3
> Wf6YgQg1Li6p//YLwHpo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Mit freundlichen Grüßen,
*Christian Beikov*

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message