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 <strub...@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 <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org