Well, anyone can invoke such a method in it's own code. The point is where the
doPrivileged block is opened.
If a method is annotated with this newly proposed @LocalPrivileged then this
method itself would NOT get wrapped with doPrivileged. But instead a private
method with a doPrivileged block will get added to the callers class and the
invocation will get replaced with that method.
Maybe I miss something, but for me that sounds safe.
LieGrue,
strub
>________________________________
> From: Matt Benson <gudnabr...@gmail.com>
>To: Commons Developers List <dev@commons.apache.org>; Mark Struberg
><strub...@yahoo.de>
>Sent: Wednesday, November 21, 2012 4:22 PM
>Subject: Re: [privilizer] new sandbox component
>
>
>
>
>
>
>
>On Wed, Nov 21, 2012 at 4:57 AM, Mark Struberg <strub...@yahoo.de> wrote:
>
>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.
>>
>>
>
>The problem with this is that the privileged APIs work such that SecurityUtils
>would still have to have full privileges; i.e., the PrivilegedAction call only
>insulates backward in the call stack, not forward. It took me ages to get my
>head around that, and ages more once I had stepped away for a couple of
>months. If SecurityUtils still has privileges graned, anyone can call its
>methods and we're back to square one.
>
>Glad to be proven wrong...
>
>Matt
>
>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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
