Hi all, Mark and I had discussed this offline some time ago, to work through the ramifications. I think his proposal is safe. For example:
org.apache.tlp.util.SecurityUtil { //simplified public static Class<?> loadClass(String classname) { return Class.forName(classname); } } Note that SecurityUtil does not use the AccessController API. The codeBase hosting this class must have privileges if #loadClass() is executed. Further, the entire hierarchy of callers must also have privileges, or have some higher level of the call have made the call within a privileged action. I explain this because this is a confusing aspect of the AccessController that has tripped me up more than once: privileges apply up the call chain, not down. Thus there is no danger in providing such hypothetical utility methods, because they are "AccessController agnostic," so to speak. Further, if we actually copy in the implementations of these methods (and I think we should do so recursively, so that if SecurityUtil#loadClass() calls some private method also defined in SecurityUtil, we copy and use it as well), we now remove the restriction that SecurityUtil's hosting codeBase must have the necessary privileges. In this example we would now have the option to simply use e.g. oacl.ClassUtils if we already had, didn't mind adding, or declared as 'provided' the [lang] dependency, further reducing code duplication. Other changes I would suggest to Mark's proposal: As illustrated by my examples, I see no reason that SecurityUtil must define @PrivilizerBlueprint. It's probably more to the point that the class *using* SecurityUtil declare that calls to methods on that class should be "privilized." We might find, however, that only certain methods are applicable. We might also find that, also suggested by my example, we want to privilize calls to methods from more than one class. I would propose that a "blueprint consumer" declare something like: @Privilizing({ @CallTo(SecurityUtil.class), @CallTo(value=ClassUtils.class, methods="getClass") }) Defined as: @Target(TYPE) public @interface Privilizing { public @interface CallTo { Class<?> value(); String[] methods() default {};//implies all } CallTo[] value(); } Now, the privilizer weaver module has the option of defining a completely separate Weaver (and I would recommend this for simplicity's sake) to handle classes annotated @Privilizing. There is no need to define anything on the class hosting the methods to be copied/privilized (and because we would copy bytecode, it should even be possible to do these recursively, in case, e.g., a user knows that oacl.ClassUtil calls some code requiring privileges via a method in oacl.StringUtil). I hope to work on this during the hackathon next week at ACNA, then kick [weaver] out of the nest shortly after. >:D Thoughts? Matt On Sun, Dec 30, 2012 at 11:05 AM, Mark Struberg <strub...@yahoo.de> wrote: > Hi! > > Not sure if this is worth doing, but could be nice from a usability pov. > > Usually projects have a lot of blocks which need doPrivileged copied over > from one class to the other. > Using @Privileged makes this a lot easier. But you still need to add > private methods to all your classes... > > > Now imagine you have a public class SecurityUtil with methods having the > annotation as in the example: > public static @PrivilizerBlueprint ClassLoader getClassLoader() {..} > > and on your other class where you like to use it you annotate the whole > class with > > @UsingPrivilizerBlueprint(my.SecurityUtil.class) > public class MyOtherClass { > public void doSomething() { > ClassLoader cl = SecurityUtil.getClassLoader(); > ... > } > > > It would already be easy with the weaver to find all the classes which > have a @UsingPrilizerBlueprint annotation. And it is also pretty easy to > scan the bytecode and create private 'inlined' methods for all the > @PrivilizerBlueprint methods (effectively copy over the bytecode for the > whole method from the util class to the using class plus do the > doPrivileged around it) and change the invocation from > SecurityUtil.getClassLoader to this.privilized_getClassLoader() > > In the afterWeave all the SecurityUtil methods which are just > @PrivilizerBlueprint methods will get changed to Modifier private. > > > That would effectively reduce the need to manually add private methods to > all your classes but instead maintain all those helper functions in a > single well maintainable place. > > If the weaver is disabled you would just use the SecurityUtil. Of course, > from a debugging pov this is not that perfect, but from a writer/user pov > it's a big benefit imo. > > > > wdyt? worth trying? > > > LieGrue, > strub > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >