[privilizer] new idea to improve usability

[Mark Struberg <st...@yahoo.de>]

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

Re: [privilizer] new idea to improve usability

[Matt Benson <gu...@gmail.com>]

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 <st...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>