Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Thu, 14 Dec 2006 14:49:21 +0100
From: Oystein Grovlen - Sun Norway <Oystein.Grovlen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-2109) System privileges
In-reply-to: <17225591.1166018903245.JavaMail.jira@brutus>
Sender: Oystein.Grovlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <45815661.2080401@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 8BIT
References: <17225591.1166018903245.JavaMail.jira@brutus>
User-Agent: Thunderbird 1.5.0.5 (X11/20060730)

Dag H. Wanvik (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458129 ] 
>             
> Dag H. Wanvik commented on DERBY-2109:
> --------------------------------------
> 
> Øystein:
>> I miss a rationale for how you ended up with three
>> database-specific features. What are particular to them compared
>> to other features like those listed in Appendix A?
> 
> I think the reason is that these can all be controlled via execute
> privileges on existing system procedures, whereas, the three new ones
> are done via getConnection and are not currently protectable. It would
> be nice to call this out earlier in the write-up - it is mentioned in the
> beginning of appendix A.
> 

That make sense, but there is at least one getConnection-operation that 
is not mentioned: Restore.  I would assume this should be a 
database-specific privelege.

-- 
Øystein