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
