Rick Tessner wrote:
>
> Hi all,
>
> I've been playing around with the sub-sitemap stuff. In particular,
> I have a <map:pipeline/> definition that looks like this:
>
> <map:pipeline>
> <map:match type="regexp" pattern="^~([^/]*)">
> <map:mount uri-prefix="~{1}" src="/home/{1}/public_xml/"
> check-reload="yes"/>
> </map:match>
> </map:pipeline>
>
> that resides in the main sitemap.xmap.
Sounds cool.
> The whole reason I'm doing this is to allow individual users
> some control over their own XSL transformation sheets. Unfortunately,
> it's also opened up a bit of a security concern.
I agree. Cocoon can be a _very_ powerful tool. One consolation
is that sub-sitemaps can't load any extra jars. And before anyone
thinks that is a good idea--it is not. It is a maintenance and
security nightmare so don't even ask for it.
I have been reading _alot_ about the Java security model. There
are some things that I am in the process of formulating to enhance
security at the ComponentManager level as well as the sitemap level.
I can guarantee you this much, the security infrastructure most
likely will be targeted at Cocoon 2.1 and Avalon 4.1. The following
is a list of my current thinking:
Avalon changes
--------------
Configuration: allow for encryption at the element level, and
delayed decryption until actually needed.
Configuration: add a method for ConfigurationBuilder to read
encrypted configuration files.
ComponentManager: Add security manager that adds a permission access
to specific roles. There are details to work out,
but it can be done. I don't know how it would work
for the ComponentSelector.
Cocoon changes
--------------
Sitemap: sitemaps extend Java's Principal with their name set to
their class name. The sitemap uses their name/id as the
Principal that accesses the ComponentManager.
Sitemap: provide ability to block specific classes to be used in
sub-sitemaps.
> In particular, user's can of course create their own XSP pages
> as well. Again, making a parallel to the Apache web server,
> there is the <Limit/> tag that can be used to limit what can
> be done in a user's own public_html directory. For instance,
> not being able to run CGI apps.
Basically, you want to remove the ability for the end user to
create XSP pages. Ok. Let me know if the security model above
won't help.
> [ I'm a wee bit concerned since an end-user, writing their own
> XSP pages would have access to any database pools that are
> defined in the cocoon.xconf. Or, am I missing something
> really obvious here?? ]
This is true. They would. We could add a method that would require
a Principal to accompany the getConnection() method. Basically, if
the configuration for the DataSourceComponent specifies any Principals
that can access the component, it would throw a SecurityException
if the plain method was used:
interface DataSourceComponent {
public Connection getConnection() throws SecurityException;
public Connection getConnection(Principal authenticatedClient)
throws SecurityException;
}
This would enable you to limit the sitemaps that could access the
Connection--or other Principals in general.
> Is there a similar mechanism for "limiting" what can be done
> in a sub-sitemap? For instance, a <map:limit> tag that
> can be used to to express that the "serverpages" generator
> cannot be accessed from a sub-sitemap? Or more generally,
> to limit components that are accessible by the sub-sitemap?
At this moment, no. Cocoon was originally designed to work as
a well behaved Servlet. That means that what you are trying to
do was not in the scope for Cocoon when it was being developed.
Let me know if there are more things that should be in the
security model I've outlined--or if you have any further input.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
