Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
2) In order to bring down the server using NetworkServerControl, the
customer will need to supply username/password credentials.
> I regard (2) as the fix to some serious bugs.
It might be useful to think about these as two separate issues, it's
really an implementation detail that DERBY-2109 addresses both of them.
The functional spec and the implementation happens to address both issues:
a) authentication with NetworkServerControl and
b) system authorization for shutdown/create database
since a) is a requirement for b). But you're right these features and their
corresponding compatibility issues could have been separated.
Item 2) does fix a bug (has it been reported as a Jira issue?) where
unauthenticated users can shutdown a network server and database engine.
So Item 2) could be fixed without system authorization (DERBY-2109)
changes, thus the justification for introducing 2) as a backwards
compatibility issue might be different to introducing 1).
I realize that my initial summary of the user-visible changes and backward
compatibility issues in SystemPrivilegesBehaviour.html (see DERBY-2109) was
incomplete.
I've updated the document to reflect that by the published patch: Issue 2)
(credentials for NetworkServerControl shutdown) arises when running with
Authentication -- with or without Security Manager.
Looking at this more it seems that item 2) only partially fixes the bug.
No, your first comment was correct. Sorry for the confusion.
If the server has system authentication but no security manager then
from a reading of the spec and the initial e-mail in this thread then
the bug remains. We may want to consider closing this security hole
regardless of if there is a security manager. This then of course would
change the backwards compatibility statement a little.
The DERBY-2109 patch fixes the authentication hole with NetworServerControl
even when running without a Security Manager. So, the issues could have
been separated.
Martin
