Thanks for trying to mediate, Sandro, but I have already considered the points you make. I'll say again the way I'm thinking, and explain how I'd look at your example. But none of my points will be new either.
On Sat, Jul 5, 2014 at 9:47 AM, Sandro Magi <[email protected]> wrote: > It seems pretty clear that the set of methods define the permission set, Yes, but only the set of methods an object implements, not the set of methods a type declares. (Unless it's "final", in which case they match.) It's an error to conclude upper bounds on authority from a type because with object subtyping, types give you a lower bound on the set of methods. It may be alarming that a static type system would essentially tell you nothing about security, but that was not the goal of Java's type system. And it isn't in itself a disaster because, say, Coyotos and E don't even _have_ static types. The dynamic checking security techniques of those systems roughly carry over; but at any rate casts aren't the issue. > and thus upcasts attenuate permissions, and downcasts amplify > permissions. Therefore, ambient downcasts are an ambient rights > amplification. No, casts do not change an object. The set of methods it implements stays the same. The permissions it provides stays the same. > Imagine a Java-like language without downcasts. Ignoring whether this is > a good design, suppose we have the following: > > class ROFile { > byte[] Read(); > void Seek(int pos); > } > class RWFile : ROFile { > void Write(byte[] data); > } > > It seems clear that no subprogram written against ROFile can write to an > underlying file, even when given an RWFile, no matter what other > subprograms it may call to do its job. Assuming all those methods are public, this is technically incorrect, because reflection would allow calling the RWFile's Write method regardless of the static type. Without reflection or downcast, you're right. In OCaml, you're right. Taking away reflection results in an object system with a very different feel. Without reflection, I'd agree that Shap's point of view is more natural, and that ambient promiscuous downcast should probably be omitted too. But I believe Java was intentionally trying to make my kind of object system, not Shap's kind. > But, as soon as you reintroduce downcasting, some subprogram could > attempt a cast to an RWFile and violate this property. Perhaps not the > immediate subprogram you call, which you may trust, but perhaps some > subprogram that *it* calls. Right. > In other words, authority is no longer the > transitive reflective closure of permission given the apparent object > type, because a downcast can amplify that object type to some more > specific type to access more methods. No, when you passed an instance of the RWFile class, you granted permission to write. Period. You don't look at the static type. If you are passing along some object you got from someone else you don't know, you have no idea what (upper bound on) permissions you're passing along, unless its static type is a final class, or you wrap it yourself. > Downcasting could perhaps be a closely held operation, but ambient > downcasting is definitely a design flaw. Perhaps you're thinking of some > usage which *necessitates* downcasting in Java, like simulating closed > sums. This is a much more limited pattern than pervasive downcasting > though. Unrestricted downcasting is a design flaw for secure programming. No I'm not thinking about use cases, I'm thinking about worst cases. In your example in the presence of ambient downcast, clearly something is wrong if you didn't mean to grant write permission. You and Shap say allowing downcast was wrong. I'm saying passing a RWFile was wrong. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
