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