You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by bu...@apache.org on 2008/05/01 18:28:44 UTC
DO NOT REPLY [Bug 44918] New: Allow to pass a custom config.
xml resource path via Init.init() method
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
Summary: Allow to pass a custom config.xml resource path via
Init.init() method
Product: Security
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Signature
AssignedTo: security-dev@xml.apache.org
ReportedBy: gigerstyle@gmx.ch
If xmlsec is used in an container env, every webapp can now use its own config
and
and dont rely on the global one.
Attached is a patch which is tested against xmlsec trunk.
Feel free to include/modify/extend/decline the attached patch
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #6 from Marc Giger <gi...@gmx.ch> 2009-06-23 07:33:38 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > Sean,
> >
> > Yes, we always pass the custom config via
> > org.apache.xml.security.resource.config
> > property. The problem with this solution is the inability to specify different
> > configs for e.g. different webservices in the same Container/VM.
>
> Ok, but I believe that requires changes to support multiple configurations in
> the same VM. Right now, there is only one configuration per VM.
> So this patch doesn't solve that problem.
I think it does;-) but perhaps I didn't express myself correctly:
What I meant is when I have multiple web-apps deployed (e.g webservices) and
every deployment has it's own copy of xmlsec.jar then the
org.apache.xml.security.Init class will be loaded multiple times, once per
webapp beause of the class loader hirarchy. No?
>
> > On the other hand I see your point with the security concern.
> > Perhaps we can add a custom Permission class to check against current active
> > SecurityManager/SecurityPolicy if we are allowed to set the config? Altough
> > I've never done this.
> >
> > What do you think?
>
> I think if you added a per-App/container configuration such that it wouldn't
> affect any other threads in the same VM then you may not need to protect it
> with a permission.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #5 from sean.mullan@sun.com 2009-06-23 06:57:41 PST ---
(In reply to comment #4)
> Sean,
>
> Yes, we always pass the custom config via
> org.apache.xml.security.resource.config
> property. The problem with this solution is the inability to specify different
> configs for e.g. different webservices in the same Container/VM.
Ok, but I believe that requires changes to support multiple configurations in
the same VM. Right now, there is only one configuration per VM.
So this patch doesn't solve that problem.
> On the other hand I see your point with the security concern.
> Perhaps we can add a custom Permission class to check against current active
> SecurityManager/SecurityPolicy if we are allowed to set the config? Altough
> I've never done this.
>
> What do you think?
I think if you added a per-App/container configuration such that it wouldn't
affect any other threads in the same VM then you may not need to protect it
with a permission.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #7 from sean.mullan@sun.com 2009-06-23 07:48:52 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Sean,
> > >
> > > Yes, we always pass the custom config via
> > > org.apache.xml.security.resource.config
> > > property. The problem with this solution is the inability to specify different
> > > configs for e.g. different webservices in the same Container/VM.
> >
> > Ok, but I believe that requires changes to support multiple configurations in
> > the same VM. Right now, there is only one configuration per VM.
> > So this patch doesn't solve that problem.
>
> I think it does;-) but perhaps I didn't express myself correctly:
> What I meant is when I have multiple web-apps deployed (e.g webservices) and
> every deployment has it's own copy of xmlsec.jar then the
> org.apache.xml.security.Init class will be loaded multiple times, once per
> webapp beause of the class loader hirarchy. No?
Ok, I see now. Yes, I believe you're right.
Let me think about this some more and get back to you.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #2 from coheigea <co...@apache.org> 2009-06-22 04:44:27 PST ---
This patch seems fine to me. Sean, can you confirm?
Colm.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #3 from sean.mullan@sun.com 2009-06-22 11:58:35 PST ---
This patch contains a potential security hole which can allow untrusted code
(ex: an unsigned applet) to replace the xml security configuration which could
be part of a trusted installation.
You can already specify a custom configuration by setting a system property and
this is more secure since your code needs to have permission to set that
property.
To the submitter: have you tried specifying your custom config with the
org.apache.xml.security.resource.config property?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.xml resource
path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #4 from Marc Giger <gi...@gmx.ch> 2009-06-22 23:40:01 PST ---
Sean,
Yes, we always pass the custom config via
org.apache.xml.security.resource.config
property. The problem with this solution is the inability to specify different
configs for e.g. different webservices in the same Container/VM.
On the other hand I see your point with the security concern.
Perhaps we can add a custom Permission class to check against current active
SecurityManager/SecurityPolicy if we are allowed to set the config? Altough
I've never done this.
What do you think?
Marc
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 44918] Allow to pass a custom config.
xml resource path via Init.init() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44918
--- Comment #1 from Marc Giger <gi...@gmx.ch> 2008-05-01 09:32:35 PST ---
Created an attachment (id=21898)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=21898)
allow to pass custom config
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.