You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by "Andrew Jaquith (JIRA)" <ji...@apache.org> on 2008/01/24 23:56:35 UTC
[jira] Commented: (JSPWIKI-155) Allow customisation of core classes
via ClassUtil.getMappedObject
[ https://issues.apache.org/jira/browse/JSPWIKI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562273#action_12562273 ]
Andrew Jaquith commented on JSPWIKI-155:
----------------------------------------
Now that I understand the capabilities of getMappedObject() better, I am going to go on record and say that this feature was and is a very bad, bad idea. I know that it was meant as a developer feature. But I think it's fundamentally dangerous, because it could totally subvert what classloading is supposed to be all about. I have never seen or heard of any other mature Java project that does anything like this -- and there's probably a good reason for that.
Based on the e-mail trail that we've had so far, it is clear that this bug is masking another: namely, a problem Simon's having getting JSPWiki working with ACEGI. That's the root of this, right? If so, let's fix that bug, not this one, and make a dangerous feature even worse.
I recommend in the strongest, most unambiguous terms that we close this bug as "won't fix." Moreover, I'd like to suggest that we completely remove the class-mapping features of ClassUtil. I acknowledge its power for certain developers, but it is a security disaster waiting to happen. Developer convenience features shouldn't be in production code.
> Allow customisation of core classes via ClassUtil.getMappedObject
> -----------------------------------------------------------------
>
> Key: JSPWIKI-155
> URL: https://issues.apache.org/jira/browse/JSPWIKI-155
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core & storage
> Affects Versions: 2.6.0
> Reporter: Simon Kitching
> Priority: Minor
>
> The WikiEngine class uses the ClassUtils.getMappedObject method to locate its critical helper objects, rather than just call "new".
> The intentention of this existing code is for people to be able to override the core implementations with custom ones - with the warning that these core objects do not have stable public apis, and may change in any release. Unfortunately because (a) the returned object is cast to a concrete type, and (b) many of these concrete types are declared "final" this facility is actually almost useless.
> It would be nice for the "final" to be removed from these classes, and from their member methods so that getMappedObject becomes useful. Alternately, interfaces could be created for the concrete classes that WikiEngine currently uses, and all code modified to use the interface instead; the existing implementations could then remain final. That approach is much more intrusive though.
> Note that in discussions on the email lists it has been suggested that the "final" qualifier on these classes helps make jspwiki more secure. Personally I'm not at all convinced that is true though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JSPWIKI-155) Allow customisation of core classes via ClassUtil.getMappedObject
Posted by Andrew Jaquith <an...@mac.com>.
Murray -- just for my own edification, what classes are you
substituting? I'd really curious to know how widely this is being used.
Andrew
On Jan 24, 2008, at 11:34 PM, Murray Altheim wrote:
> Andrew Jaquith (JIRA) wrote:
>> [ https://issues.apache.org/jira/browse/JSPWIKI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562273
>> #action_12562273 ] Andrew Jaquith commented on JSPWIKI-155:
>> ----------------------------------------
>> Now that I understand the capabilities of getMappedObject() better,
>> I am going to go on record and say that this feature was and is a
>> very
>> bad, bad idea. I know that it was meant as a developer feature. But I
>> think it's fundamentally dangerous, because it could totally subvert
>> what classloading is supposed to be all about. I have never seen or
>> heard of any other mature Java project that does anything like this
>> --
>> and there's probably a good reason for that. Based on the e-mail
>> trail that we've had so far, it is clear that this bug is masking
>> another: namely, a problem Simon's having getting JSPWiki
>> working with ACEGI. That's the root of this, right? If so, let's
>> fix that bug, not this one, and make a dangerous feature even worse.
>
> Yes, agreed.
>
>> I recommend in the strongest, most unambiguous terms that we close
>> this bug as "won't fix." Moreover, I'd like to suggest that we
>> completely remove the class-mapping features of ClassUtil. I
>> acknowledge
>> its power for certain developers, but it is a security disaster
>> waiting
>> to happen. Developer convenience features shouldn't be in
>> production code.
>
> Hi Andrew,
>
> Removing this feature would *completely* shut down my embedded use
> of JSPWiki, killing off further use of JSPWiki utterly and entirely.
> Therefore I can only respond that in the strongest, most unambiguous
> terms we not remove the class-mapping features of ClassUtil.
>
> As a way of mitigating its abuse, might I suggest a simple boolean
> flag,
> that once set following completion of WikiEngine's instantiation,
> disables further class mapping? I only need to use class mapping
> during
> instantiation of the WikiEngine itself; after that it admittedly
> becomes
> only a security issue (which is why I didn't want it opened up any
> further in order to 'solve' Simon's bug).
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray07 at altheim.com>
> === = =
> http://www.altheim.com/murray/ =
> = ===
> 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
Re: [jira] Commented: (JSPWIKI-155) Allow customisation of core classes
via ClassUtil.getMappedObject
Posted by Murray Altheim <mu...@altheim.com>.
Andrew Jaquith (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/JSPWIKI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562273#action_12562273 ]
>
> Andrew Jaquith commented on JSPWIKI-155:
> ----------------------------------------
>
> Now that I understand the capabilities of getMappedObject() better, I
> am going to go on record and say that this feature was and is a very
> bad, bad idea. I know that it was meant as a developer feature. But I
> think it's fundamentally dangerous, because it could totally subvert
> what classloading is supposed to be all about. I have never seen or
> heard of any other mature Java project that does anything like this --
> and there's probably a good reason for that.
>
> Based on the e-mail trail that we've had so far, it is clear that this
> bug is masking another: namely, a problem Simon's having getting JSPWiki
> working with ACEGI. That's the root of this, right? If so, let's fix
> that bug, not this one, and make a dangerous feature even worse.
Yes, agreed.
> I recommend in the strongest, most unambiguous terms that we close
> this bug as "won't fix." Moreover, I'd like to suggest that we
> completely remove the class-mapping features of ClassUtil. I acknowledge
> its power for certain developers, but it is a security disaster waiting
> to happen. Developer convenience features shouldn't be in production code.
Hi Andrew,
Removing this feature would *completely* shut down my embedded use
of JSPWiki, killing off further use of JSPWiki utterly and entirely.
Therefore I can only respond that in the strongest, most unambiguous
terms we not remove the class-mapping features of ClassUtil.
As a way of mitigating its abuse, might I suggest a simple boolean flag,
that once set following completion of WikiEngine's instantiation,
disables further class mapping? I only need to use class mapping during
instantiation of the WikiEngine itself; after that it admittedly becomes
only a security issue (which is why I didn't want it opened up any
further in order to 'solve' Simon's bug).
Murray
...........................................................................
Murray Altheim <murray07 at altheim.com> === = =
http://www.altheim.com/murray/ = = ===
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