tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Policy files
Date Thu, 25 Apr 2013 17:10:32 GMT
Hash: SHA256


On 4/24/13 11:25 PM, Christian Beikov wrote:
> 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'm curious as to what permissions you want them to have while
restricting others. Can you give some examples?

> 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.

I understand what you are saying, but examples would certainly help.

> 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.

I actually had no idea that WebappClassLoader had a set of
"addPermission" methods. I'll have to read more about those.... they
seem to give access to the parent classes (URLClassLoader,
SecureClassLoader)'s permissions lists. Cool if it works.

I honestly had no idea that some ClassLoaders maintain their own
permissions lists.

> 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.

If you want this, then you'll have to do a couple of things:

1. Make sure the context.xml always has the stuff you want (and isn't
under control of the student, for instance -- otherwise they can just
give themselves whatever permissions they want)

2. Create a ServletContextListener that runs on startup

3. Your listener needs to parse your policy and apply it to the
WebappClassLoader. I wouldn't be surprised if the webapp itself is not
permitted to add permissions to the WebappClassLoader. You might have
to put your ServletContextListener higher-up in the ClassLoader
hierarchy in order to be allowed to call that method.

4. Figure out how to parse a policy file.

Note that #4 just means /your/ policy file. It doesn't have to be a
classic "Java Policy File". You could have a simple policy file like this:

Then you can parse it any way you like. Use XML if it's more convenient.

> 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.

If you don't know what permissions they would need, maybe you should
wait until you actually need to give those permissions before you
spend a lot of time building infrastructure to support granting them.

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

If it were me, I'd look at a particular project and imagine any
privileges you'd need to give to a webapp in order for it to function.
For instance, if you have a webapp that is just a "Hello World" then
you don't need any permissions.

If you need to access a database, then you'll need to give them access
to that, too. If everyone needs access to the same database, maybe
just make it a top-level permission that all code can access
localhost:1234 or whatever in order to contact the database.

I think you'll find that lots of what you want can be configured at
the global level without worrying too much about assigning permissions
to individual webapps. Instead, all webapps will likely need the same
permissions (e.g. reflection) and you can simply give *all* code in
the JVM permissions to do that.

Then you have much less code to write.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message