Thanks to everybody for the discussion so far. And thanks to Martin for
revising the SystemPrivilegesBehaviour.html summary attached to
DERBY-2109. I think that my initial posting garbled the description of
the compatibilty issues. I would like to restate what the
backward-compatibility issues are:
1) Customers running unsecurely (no Authentication and no Java Security):
No compatibility issues.
2) Customers running just with Java Security (but no Authentication):
No compatibility issues.
3) Customers running just with Authentication (but no Java Security):
a) Must provide valid credentials when using NetworkServerControl to
shutdown the server.
4) Customers running with BOTH Authentication and Java Security:
a) Must provide valid credentials when using NetworkServerControl to
shutdown the server.
b) Must add additional privileges to the Java Security policy file
(unless the default policy file is used)
So far I have not heard any objections to (a).
Misgivings have been expressed about (b): It complicates application
upgrade for apps which run securely. For these apps, upgrade is no
longer just a matter of copying a jar file. Now some wrapper code must
perform the upgrade, copying the jar file and adjusting the policy file.
I don't know how onerous this is. For me at least, it seems that
whenever I upgrade a commercial-grade app these days, the upgrade is
driven by an intelligent installer.
Misgivings have also been expressed about the misgivings about (b): the
longer we delay this change, the more customers will be affected.
Are there other concerns which we should collect before polling the user
community for their opinion?
Thanks,
-Rick
Rick Hillegas wrote:
The system privileges work (DERBY-2109) will introduce a compatibility
issue for 10.4. I would like to commit Martin's work on this issue,
but before I do that, I would like to make sure that the community is
comfortable with the compatibility behavior. I am taking this question
to the developer community first. Once the developer community agrees
on the correct behavior, it may be necessary to poll the user
community as well.
DERBY-2109 reduces our exposure to denial-of-service (and possible
theft and corruption) attacks by making it possible to restrict who
can bring down the engine and create databases. However, in providing
these extra protections, DERBY-2109 introduces a
backward-compatibility issue. This issue affects customers who do BOTH
of the following:
A) Run with Authentication turned on
B) Run with a Java Security Manager
After upgrading the engine code to 10.4, these customers will
experience behavior which is different from 10.3:
1) If the customer has written their own security policy file (the
usual and recommended situation), then the customer will need to add
some extra permissions to that policy file.
2) In order to bring down the server using NetworkServerControl, the
customer will need to supply username/password credentials.
I expect that item (1) will affect most production usages of Derby
which run under a Java security manager. In essence, we are requiring
that these customers declare the list of users who are trusted to
shutdown the engine and create new databases. Item (1) will also
affect IDEs and other development tools which generate their own Derby
policy files rather than relying on the default policy file supplied
with the product.
I expect that item (2) will affect most Derby applications which run
in client-server mode. I regard (2) as the fix to some serious bugs.
Today any valid account on the server machine can bring down someone
else's network server. In addition, anyone who shuts down the server
via NetworkServerControl is essentially crashing the engine today.
This is because credentials are not supplied to the connection which
tries to shut down the engine; as a result, engine shutdown fails on a
credentials check and the engine is forcibly crashed when the server
later exits the VM. See
http://www.nabble.com/Shutdown-Network-Server-w--auth-enabled-to11781943.html#a11781943
Personally, I believe that the enhanced security and bug fixes
provided by DERBY-2109 justify the backward-compatiblity issues.
Does anyone object to these incompatibilities?
Thanks,
-Rick
