> On Apr 4, 2017, at 10:45 AM, Andrew Dinn <ad...@redhat.com> wrote:
>
> On 04/04/17 15:58, Gregg Wonderly wrote:
>> Alan said:
>>
>>> The issue here is nothing to do with the security manager, assume
>>> no security manager in the picture.
>>
>> But, I always have a security manager in the picture. It’s how I
>> always grant access to various pieces of the JDK features to my
>> application. It’s how I limit/grant access to the details that I
>> care about my users being exposed to by using my software. So,
>> saying that a SecurityManager doesn’t matter, when this is clearly a
>> JVM security issue, just doesn’t fly for me. As I’ve already said,
>> a command line argument can feel like a permission, but it is like
>> AllPermission. It doesn’t help me manage what I am opening my users
>> to. If I have to use the AllPermission for my users to deploy, and
>> they are on a network, I’ve now opened them up to network penetration
>> by other agents! That’s absolutely not acceptable to me.
>
> That may be so but, as Alan said, there are many other Java users who
> have never had a security manager in the picture. You seem to be
> assuming that we can rely on users to correct that omission as an
> element of how we address this problem. I'd suggest that is just as
> questionable -- indeed, probably more so -- as assuming that we can
> rely on users to remember to reset the current proposed default to
> enable dynamic agents.
Let me put together my whole argument again.
1) People can edit jar files and completely obliterate any security settings
expressed in those files.
2) People can add JNI modules and have complete access to all details of the
JVM environment.
3) People can recompile the openJDK JVM to turn off anything that they want
about this development.
4) People are going to have to use command line switches to control this
behavior in environments where their current applications are broken by Jigsaw
changes.
So, in the end, integrity, modularity and ultimately the goals of this project
can only be maintained by active participation from the community of developers
which we hope will all be capable, and able to participate because their use of
the JVM (for other JVM languages besides Java) can deal with these changes.
This whole effort relies on developers to make it possible for users of java to
succeed at using JDK-9. If developers don’t do that, or can’t do that because
of limitations of JigSaw, this will be like windows-7 users. There will be a
lot of old cruft setting around giving Java a bad name because it won’t be
current and the new version of Java broke it.
I am not trying to be a arse about this. I am being forthright and direct with
my comments and recommendations because I believe that’s the best way to not
beat around the bush.
> Please try to assume that Alan might be arguing for a more nuanced
> position than the one you assumed when his argument appears to be making
> no sense to you. He is neither stupid nor ignorant of what a security
> manager can and cannot do. If anything he says leads you to question
> dconfirming such an opinion before posting it.
I am not one to assume anything. That’s a big fault of failing discussions.
Everything needs to be on the table here. What’s important to me, is important
to me. What’s important to another group of developers, is important to them.
What is not helping me be comfortable with this, is the simple fact that
nothing done here, guarantees anything without developers participating
“nicely”.
At the forefront of the failure of the SecurityManager to be an avidly used
element of Java applications, is the simple fact that the whole infrastructure
is horribly inefficient and full of locks and mutable data which should not be
locked and should instead be immutable. But, because “assume no security
manager in the picture” is the state of “the world”, the details have not been
fixed, officially. In the Jini community, Peter Firmstone (most of the recent
work), and I, have spent quite a bit of time on understand and fixing these
issues. He has tried to push the knowledge of what needs to be done into
various places, which I don’t recall at the moment.
In the end because JDK-9 breaks everything (well not quite, but nearly, since
spring and other similar libraries are broken), requiring command line
arguments, why not just finally fix Java by instituting a default
SecurityManager, instead of the command line flags, which enforces all of these
things. Why not just require the added command line argument to be the
permissions file to use? It seems just insane, to me, for all of this
infrastructure to exist, which does exactly what all of these command line
arguments are going to essentially do (turn the permission to do something
on/off) and then to just summarily go around it and completely ignore it.
I don’t know how else to say anything here more constructively without
continuously pointing at the fact that I think this just completely BOTCHES the
JVM with nonsense changes trying to recreate SecurityManager features, which
already exist. That’s where my “Do you know what the SecurityManager does?”
argument comes from. I just cannot look past this work and say, oh, yeah, lets
put in some other form of “key” to the kingdom so that developers and users of
Java have yet another way to do exactly the same “mechanisms” that we already
have.
It make absolutely no sense to me.
And I am being harsh and direct to invite comments and explanations and
arguments about the pros of what is being done, not to try and shut people up
because they think I just want to whine and fuss about this.
Gregg
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
