Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 15 Jan 2008 14:43:46 -0800
From: Martin Zaun <Martin.Zaun@Sun.COM>
Subject: Re: Compatibility issue for 10.4
In-reply-to: <478CE23A.1070604@apache.org>
Sender: Martin.Zaun@Sun.COM
To: derby-dev@db.apache.org
Message-id: <478D3722.3010205@sun.com>
Organization: Sun Microsystems, Inc.
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <478B94A5.1080502@sun.com> <478CDD1E.7070807@apache.org>
 <478CE23A.1070604@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4)
 Gecko/20070509 SeaMonkey/1.1.2


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