commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [privilizer] new sandbox component
Date Wed, 21 Nov 2012 23:31:03 GMT
Perhaps showing an example of what the resulting code would look like
might help?

On Wed, Nov 21, 2012 at 6:10 PM, Mark Struberg <struberg@yahoo.de> wrote:
> 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 <gudnabrsam@gmail.com>
>>To: Commons Developers List <dev@commons.apache.org>; Mark Struberg <struberg@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 <struberg@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 <gudnabrsam@gmail.com>
>>>>To: Commons Developers List <dev@commons.apache.org>; Mark Struberg
<struberg@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 <struberg@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 <gudnabrsam@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.steitz@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-unsubscribe@commons.apache.org
>>>>>>>  For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message