incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <>
Subject Re: Classmapping and final classes
Date Tue, 22 Jan 2008 08:46:15 GMT
Simon Kitching wrote:
> Murray Altheim schrieb:
>>> In the meantime, for this particular case, I'd recommend that Simon
>>> file an enhancement request or bug in JIRA, and folks with embedding
>>> expertise (like Murray) can help figure out an approach that would
>>> work. If we need to do a little design work for 2.8, great. And if
>>> that's doesn't come soon enough for him, he's always got the option
>>> of patching the code himself temporarily.
>> Agreed. I can't see justification for a big, known security hole.
>> Patching ClassUtil by removing several 'final' declarations should be
>> the province of an individual hack (and a very simple one at that), not
>> part of the core. IMO.
> Thanks very much to you all for your comments on this so far.
> The reason I want to change the behaviour of AuthenticationManager and
> AuthorizationManager is that I am trying to embed jspwiki into a webapp
> (no ejb) that uses ACEGI security, not jaas. The base classes just do
> not support this AFAICT. And the app into which it is to be embedded
> also has its own user state and group information. Please note that I
> don't know a lot about servlet container security; perhaps there is a
> way to configure jaas to map through to ACEGI but if so I don't know it;
> I'd rather avoid all that if possible.
> Things like UserManager and GroupManager are nicely designed to delegate
> through to the UserDatabase and GroupDatabase classes which are
> pluggable. I had no need to override the manager classes to customise
> these as needed; the database classes were sufficient to give jspwiki
> access to the necessary data from the enclosing app.


> However the AuthenticationManager and AuthorizationManager encode a lot
> of logic and policy into the base classes; overriding just the
> Authenticator/Authorizer classes is not enough to get proper control.
> Some of the problem behaviour can be turned off by setting
> "", which sets the c_useJAAS flag and so skips some
> jaas behaviour, but unfortunately it skips too much code.

If you're doing a major overhaul of JSPWiki's authentication and authori-
zation it would seem that taking the existing AuthenticationManager and
AuthorizationManager classes as starting points and rewriting them (not
extending the existing) as necessary would be the way forward. Then,
using the existing feature of the ClassUtil (without modification), you
add your class mappings to ClassUtil's classmappings.xml file:

    public static final String MAPPINGS = "/ini/classmappings.xml";

then let WikiEngine instantiate them using the existing code:

    m_authenticationManager = (AuthenticationManager)
    m_authorizationManager  = (AuthorizationManager)
            ClassUtil.getMappedObject( AuthorizationManager.class.getName());

I don't see how a modification of ClassUtil is necessary here. The real
grunt work is rewriting the two AA classes. But so far as I understand
your requirements, the existing machinery permits this.

> I don't understand why you would think that a non-final class would be
> any less secure than a final one. The reasons for making a class final are:
> * so that you don't have to worry about API stability for subclasses
> * in order to improve performance

Making a class final is also simply to prevent extension (which is true
for APIs as well as any other class uses). One of the principal reasons
to prevent extension is for security.

> I cannot imagine an attack that would be prevented by making this class
> final. I guess someone could provide a plugin that provides a
> classmapping.xml file on the classpath. But even then that would have no
> effect because these manager classes are all resolved at startup, before
> plugins are scanned.

It's a general purpose utility that has by its nature the ability to
alter which classes are instantiated at any given time -- that in itself
is great opportunity for cracking into a wiki, from all sorts of angles.
It's just IMO not the kind of tool one would want to leave open to abuse.

> Note that if I have access to the classpath, I can simply place my own
> version of this class earlier in the classpath, in which case it
> overrides the one that comes with jspwiki anyway. I haven't decided
> quite how to manage the use of a patched version of jspwiki yet; I might
> even use this approach myself (creating an _jspwiki-patch.jar that
> contains modified versions of the problem files, then also including an
> unmodified jspwiki.jar file). Providing a "sealed" jar, ie adding
> metadata that marks it as a non-extendable package, then digitally
> signing the jar, would block this "security hole" but I'm sure you don't
> want to go to those lengths.

As you point out, there's no security issue there because all of that
occurs either during installation or as the wiki is firing up. But I've
never needed to go to any of those lengths myself. You might investigate
the cascading property feature as well as ClassUtil.MAPPINGS if you haven't

> BTW, it's not final methods in ClassUtil that are the problem, but final
> methods in AuthorizationManager and AuthenticationManager.

Yes, but you probably just need to rewrite those classes anyway since
you're not using the same AA model. Perhaps I'm not understanding where
the problem really is, i.e., it would seem to be a case of rewriting
those two classes and setting the mappings so that ClassUtil instantiates
your rewritten classes rather than the existing two.


Murray Altheim <murray07 at>                           ===  = =                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record

View raw message