Re: [privilizer] new sandbox component

[James Carman]

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  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 
>>To: Commons Developers List ; Mark Struberg 
>>
>>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  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 
>>>>To: Commons Developers List ; Mark Struberg 
>>>>
>>>>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  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 implement

Re: [privilizer] new sandbox component

[Mark Struberg]

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 
>To: Commons Developers List ; Mark Struberg 
> 
>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  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 
>>>To: Commons Developers List ; Mark Struberg 
>>>
>>>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  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, 

Re: [privilizer] new sandbox component

[Matt Benson]

On Wed, Nov 21, 2012 at 4:57 AM, Mark Struberg  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 
> >To: Commons Developers List ; 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 
> 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 
> >>> To: Commons Developers List 
> >>> 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 
> >>> wrote:
> >>>
> >

Re: [privilizer] new sandbox component

[Mark Struberg]

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 
>To: Commons Developers List ; Mark Struberg 
> 
>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  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 
>>> To: Commons Developers List 
>>> 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 
>>> 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.
>>>>  >
>>>&

Re: [privilizer] new sandbox component

[James Carman]

AspectJ can weave the callers, but you have to have access to them, so
the way you're doing it seems to be safest.

On Tue, Nov 20, 2012 at 11:31 AM, Matt Benson  wrote:
> On Tue, Nov 20, 2012 at 10:12 AM, Mark Struberg  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 
>> > To: Commons Developers List 
>> > 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 
>> > 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

Re: [privilizer] new sandbox component

[Matt Benson]

On Tue, Nov 20, 2012 at 10:12 AM, Mark Struberg  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 
> > To: Commons Developers List 
> > 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 
> > 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
>
>

Re: [privilizer] new sandbox component

[James Carman]

Or, "privinator"

On Tue, Nov 20, 2012 at 11:12 AM, Mark Struberg  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.
>
> LieGrue,
> strub
>
>
>
> - Original Message -
>> From: Matt Benson 
>> To: Commons Developers List 
>> 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 
>> 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

Re: [privilizer] new sandbox component

[Mark Struberg]

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.

LieGrue,
strub



- Original Message -
> From: Matt Benson 
> To: Commons Developers List 
> 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  
> 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

Re: [privilizer] new sandbox component

[Matt Benson]

Glad 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  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
>
>

Re: [privilizer] new sandbox component

[Matt Benson]

Hi Gary,
  Hmm... the site is there as far as I can tell.  The "docs" such as they
are are the overview page of the site.  I also need to go back and include
the individual module sites so you can easily reference the Maven plugin's
generated docs.  There is an example module which demonstrates the usage
with the Maven plugin, but TBH it's all IMO so simple as to defy
documentation.  ;)

Regards,
Matt

On Mon, Nov 19, 2012 at 6:35 PM, Gary Gregory wrote:

> Hi Matt,
>
> I do not see a site under https://commons.apache.org/sandbox/
>
> Before I think about looking, are there any docs, examples, and so on?
>
> Gary
>
>
> On Mon, Nov 19, 2012 at 5: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
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [privilizer] new sandbox component

[Phil Steitz]

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

Re: [privilizer] new sandbox component

[Gary Gregory]

Hi Matt,

I do not see a site under https://commons.apache.org/sandbox/

Before I think about looking, are there any docs, examples, and so on?

Gary

On Mon, Nov 19, 2012 at 5: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
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[privilizer] new sandbox component

[Matt Benson]

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