[cap-talk] David Wagner's Google techtalk is now up!

[Mike Samuel]

On 15/12/2007, David Wagner <daw at cs.berkeley.edu> wrote:
>
> Mike Samuel writes:
> >Public classes, and classes within the same package are ambiently
> available,
> >but you contradict a lot of people's assumptions if you make private
> inner
> >classes ambiently available.
>
> Oh dear.  Well, in trying to concisely hint at Joe-E stance on this,
> my attempt at brevity came with a corresponding loss of accuracy, which
> unsurprisingly seems to have caused confusion.  My apologies.


Thanks for responding.  I assumed that since all classes were treated as
ambient, that your tamed proxy stuff didn't discriminate between classes
based on accessLevel which sounds pretty silly now that I think about it.


Thanks for following up on this.  Let me try again, this time in a bit
> more detail.  Hopefully it will alleviate your concerns.
>
> In Java, one can write
>     Class c = Foo.class;
> where Foo is any class you can name.  (For instance, you can name a
> public class, but you generally cannot name private inner classes.)
> Joe-E allows you to write Foo.class in the same cases where Java does.
>
> As for the use of runtime reflection, Joe-E will provide libraries that
> act as a wrapper around the Java reflection libraries.  Joe-E's libraries
> will include access control checks to enforce our security policy.
> The intended security policy is that you can do something at runtime
> using reflection only if you could have done it statically by writing it
> in the source code.  For instance, if the Java compiler wouldn't let you
> write foo.m() (e.g., because m() is a private method of Foo and foo's
> static declared type is Foo), then you shouldn't be able to use Joe-E's
> reflection libraries to invoke m() on foo at runtime, either.
>
> Hopefully this will be sufficient to avoid violating people's
> expectations.
>
> Does this seem like a reasonable stance?


Sounds reasonable to me.



>Proxying allows you to do things with private inner classes and
> >package private classes that you can't do statically.
>
> Joe-E's proxy libraries had better not let you do that.
> (If they do, it's a bug, but I don't think they do.)





Note that Joe-E does not expose Java reflection libraries directly;
> instead, Joe-E provides wrapper classes (written by Tyler) that enforce
> the necessary security checks.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20071217/54f1f729/attachment.html