Oki, let me explain what I meant.
Currently the methods must be private to be really secure. But having a public
method is not a problem if it does NOT contain any doPrivileged but if this
wrapper is generated as private method of the caller. So people will
As example please consider the following method in a SecurityUtils helper class:
public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }
and in another class you will have a single lined method
@Privileged
private ClassLoader getCurrentClassLoader(Class refPoint) {
return SecurityUtils.getCurrentClassLoader(refPoint);
}
If someone calls the SecurityUtil method directly from outside (and does not
use the commons-privilizer in his project or manualy wraps it with
doPrivileged), then this method will throw a SecurityException as the
SecurityManager will not allow this call.
What I was proposing is to generate the private helper method in the caller
class for the user automatically. We could e.g. do this by introducing a 2nd
annotation, e.g. @LocalPrivileged.
Writing
@LocalPrivileged
public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }
and using the commons-privilizer in the project could do that. That's of course
more work to do than the current approach, but could be worth looking at. That
could be done in a v2 release as well.
LieGrue,
strub
>________________________________
> From: Matt Benson <gudnabr...@gmail.com>
>To: Commons Developers List <dev@commons.apache.org>; Mark Struberg
><strub...@yahoo.de>
>Sent: Tuesday, November 20, 2012 5:31 PM
>Subject: Re: [privilizer] new sandbox component
>
>
>
>
>
>
>
>On Tue, Nov 20, 2012 at 10:12 AM, Mark Struberg <strub...@yahoo.de> wrote:
>
>Heh, the other option has been 'privilator'
>>
>>Catchy as well, and would have given a nice slogan: 'Privilator - I'll be
>>secure, baby'
>>
>>It's a bit less self-explaining though.
>>
>>
>>We are looking forward to use it in Apache BVal, OpenWebBeans, DeltaSpike and
>>probably MyFaces for now.
>>
>>One thing I like to give a try is to generate private method wrappers in all
>>_caller_ classes. That would even allow for public helper methods which are
>>perfectly save.
>>
>>
>
>This is a point on which Mark and I differ, so if this is implemented I prefer
>to do it as an option, perhaps using a different annotation, e.g.
>@RequiresPrivileges. My concern is that there could be any number of callers,
>so the task of finding and weaving them all is a large one (I wouldn't even
>know what existing libraries will perform for me a search for all callers of
>method Foo#bar(), and what about reflection-based invocations?), and it means
>you can't simply distribute a library and call it "privilized." :) Of
>course, none of this is anything you can't do with e.g. AspectJ, but as
>mentioned in the overview the [privilizer] code adds no runtime dependencies
>(not even its own API jar!).
>
>Matt
>
>LieGrue,
>>strub
>>
>>
>>
>>----- Original Message -----
>>> From: Matt Benson <gudnabr...@gmail.com>
>>> To: Commons Developers List <dev@commons.apache.org>
>>> Cc:
>>> Sent: Tuesday, November 20, 2012 6:40 AM
>>> Subject: Re: [privilizer] new sandbox component
>>>
>>>G lad to hear it, Phil! I was originally calling it "privileged method
>>
>>> weaver" but that's a little long for a Commons component. Mark
>>> Struberg
>>> came up with "privilizer" for me--short, but still fairly suggestive
>>> of the
>>> component's purpose.
>>>
>>> Matt
>>>
>>>
>>> On Mon, Nov 19, 2012 at 8:04 PM, Phil Steitz <phil.ste...@gmail.com>
>>> wrote:
>>>
>>>> On 11/19/12 2:42 PM, Matt Benson wrote:
>>>> > Hi all,
>>>> > I have recently been working on some code to simplify the task of
>>>> working
>>>> > with the Java security APIs and an ASF colleague convinced me that the
>>>> > package had a chance of being a viable Commons component. I have
>>> added
>>>> it
>>>> > to the sandbox and it is available on the website by now as well.
>>>> > Typically code that is too "done" doesn't fare too well
>>> at the ASF in
>>>> > general; one obvious improvement that might be made would be the
>>>> > replacement of Javassist with ASM or perhaps BCEL, but the existing
>>>> > implementation represented a path of least resistance for me. Anyway,
>>>> I'd
>>>> > be glad for any feedback, questions, or tomatoes.
>>>> >
>>>> > Thanks,
>>>> > Matt
>>>> >
>>>> Sweet! I recently had need for exactly this. Lets argue about the
>>>> name - or not ;) I love it!
>>>>
>>>> Phil
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
