[
https://issues.apache.org/jira/browse/DERBY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470418
]
Dag H. Wanvik commented on DERBY-2264:
--------------------------------------
Thanks for your analysis! I basically agree.
Stretching it, I can see a use for 2) in a development situation, while
experimenting with privileges as different users etc. In deployment, no, I
agree, it does not make much sense. A ported app which uses GRANT/REVOKE for
which you don't care less about authentication, perhaps. Number 6) seems even
less useful.
3) and 7) might make sense for a set of cooperating users; using GRANT/REVOKE
is more rigid, after all. But as you point out, we must expect (*,on,off) is in
use by legacy applications.
What I argue in my previous post is that it does not make sense to forbid
shutting down the database if you already can delete all its data, which is the
case for 7 for fullAccess users. IIt can also break existing apps, which makes
it even less palatable. So even if we make 7 the default for our
secure-by-default server, I propose we only enforce the checks called for by
this JIRA in case 4) and 8), not for 3) or 7). We could even drop the checking
for 4), since the user can shut down the system, anyway, but I am not proposing
that now, to keep things simple.
> Restrict shutdown, upgrade, and encryption powers to the database owner
> -----------------------------------------------------------------------
>
> Key: DERBY-2264
> URL: https://issues.apache.org/jira/browse/DERBY-2264
> Project: Derby
> Issue Type: New Feature
> Components: Security, SQL
> Reporter: Rick Hillegas
> Attachments: dbaPowers.html, dbaPowers.html
>
>
> This JIRA separates out the database-owner powers from the system privileges
> in the master security JIRA DERBY-2109. Restrict the following powers to the
> database owner for the moment: shutdown, upgrade, and encryption.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
