On 08/27/2014 04:04 PM, mark.reinh...@oracle.com wrote:
2014/8/27 1:13 -0700, david.ll...@redhat.com:
...
I think this is the fundamental difference. You think "deterrent". I
think "expectation management". People who *want* the functionality
will get it; it is a far more efficient expenditure of energy to let
them do it and just clearly manage expectations than to try to modify
behavior (which will just result in frustration for users).
As Alan noted, the experience of those of us working on the JDK itself
has been rather different. We've warned against using internal APIs for
years, but it's had little effect. In the meantime all this cruft upon
which people have come to depend has gradually grown into a significant
maintenance burden. It's time to cut the cord.
Adding
artificial barriers is counter-productive, and may even introduce
security risks as yet more JVM security mechanisms are added on top of
the existing stuff (a lesson that the constant CVE avalanche indicates
has not been fully learned yet, especially in the context of Java).
We're trying to improve security, and we suspect we can do this in a
reasonably straightforward way. Enforcing module boundaries in the VM
would be a big improvement over the existing means of protecting JDK
internals (e.g., SecurityManager::checkPackageAccess), which are are
brittle and error-prone.
...
I don't know about that. We're talking, as always, about the concepts
of visibility as opposed to accessibility. Until now, all discussion
has been in the context of visibility, which as I said (and MR agreed)
is easily subverted - but then MR said he intends to "enforce module
boundaries via access-control checks in the VM" which blurs the line
considerably. So if we're now moving into accessibility territory
across class loaders, we're definitely and squarely overlapping with
AccessController and its related facilities - i.e. "does module X have
permission to import module Y?".
The type of module-boundary access-control check we're thinking of would
be an extension of what the JVM currently does during class, interface,
field, and method resolution, per JVMS 5.4.4 [1]. It's the exact same
mechanism that keeps private members private, and it's very difficult to
subvert. It has little (direct) relation to AccessController or any
kind of security-permission check.
An intra-classloader or intra-module access level akin to package
access, as previously described in the initial stages of Jigsaw, is
easily understood since this is just another access protection flag in
class files and is fairly easily accomplished. However once you start
allowing modules to specify what modules may import from it (by name,
presumably), you're now forced to define the scope of the names you're
assigning, and thereby implicitly increasing the user's need to maintain
security and integrity not just within modules, but also between them.
IMO this in turn will imply (even more strongly than before) a loading
level that corresponds to the aggregation of modules within a general
namespace, which can manage the loading of modules as well as the
assignment of their "friends", similarly to how class loaders (and in
the future, I expect, modules) are responsible for the security and
integrity of loading the classes and resources that comprise it.
Am I far off the mark here?
I do believe that there is still a strong overlap between the functions
of AccessController and this mechanism though, in any event (not that
I'm a great fan of that mechanism in general). But maybe the module
mechanism can provide additional ways to improve it somehow, or perhaps
even to replace it, eventually.
--
- DML
