This isn't necessarily surprising; but it can be a pain.
First, some helpful links: The Security Manager HOW-TO in Apache's Tomcat documentation explains the basics. For specifics on the format of permission entries, see Sun's documentation on Default Policy Implementation and Policy File Syntax.
Notes:
- Tomcat's policy settings are (on my Ubuntu box) in
/usr/share/tomcat5.5/conf/catalina.policy
. But heed the warning in the file's header: If your system is Debian-esque (and that includes Ubuntu) then that file is auto-generated from a set of files inconf/policy.d
, and those are the ones you want to be editing. Permissions you want to add for your web apps will likely best fit in50user.policy
. - The policy files are concatenated and the settings initialized when Tomcat starts. Hence, you need to restart Tomcat in order for permission changes to have an effect.
- The
codeBase
string is a URL, so it always takes forward slashes. File names forFilePermission
may be operating system dependent, so you should use${file.separator}
instead there. - As explained in the Sun doc, an asterisk (
*
) in a path forFilePermission
(roughly) means "everything in this directory", while a dash (-
) means "everything in this directory and recursively in all subdirectories". Likewise, the beginning of a host address forSocketPermission
may be wildcarded with an asterisk. In the extreme case, the entire host address may be an asterisk and so will apply to "any host". - If you're having trouble getting permissions to take effect, you can try narrowing down the problem by making either the codeBase universal (surprisingly, the "codeBase" descriptor is optional, so it's quite legal to have a stanza that starts with "
permit {
" or the permission all-encompassing: that would be "java.security.AllPermission
". Once you get stuff working with this gaping security hole, you will want to go back and try to tighten it up again.
No comments:
Post a Comment