db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2264) Restrict shutdown, upgrade, and encryption powers to the database owner
Date Wed, 07 Feb 2007 17:32:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471037

Dag H. Wanvik commented on DERBY-2264:

Thanks for good points, Dan! I am still a little unsure of what would
be the best approach here, though. As far as I understand it, we need
to strike the right balance between a) plugging security holes, b)
avoiding undue complexity and c) reducing upgrade pains as much as

3) and 7): Good point about readOnly users; I agree restricting DBA
powers here plugs a sizable hole. For fullAccess users, your argument
that the permission to e.g. shut down the database is a different
permission from full data access is obviously true. My concern,
however, is how to weigh the benefit of restricting this permission
against the risk of breaking existing applications.  I think this risk
is real; I did some experiments and found that under the current
regime for 3) and 7), the developer does not really need to worry
about who is the database owner. It is easy to create a database whose
owner is APP, which can not be authenticated either at the system or
database level, and the developer would not presently notice, since no
enforcement is in place. This is compounded by the docs not being very
explicit about how the database owner is created.  The workaround for
an application broken by the new enforcement in such a case, would be
to a) create a database user called APP to match the system schema
user name effectively creating the "owner", and b) always close down
the database connecting as APP.

One possible way to balance the concerns is to enforce only for
readOnly access users, thus effectively allowing fullAccess users
database owner powers for 3) and 7). My theory is that this would
reduce upgrade pains at slight cost. If this security is not good
enough for new application, the user can move to sqlAuthorization.
Downside is more slightly more complexity. What do you think?

If we decide to go with enforcement also for fullAccess users in 3)
and 7), we need make a good release note, at least, and clarify docs.

Dan> I think you also cannot assume that a user authenticated by a
Dan> database is a valid user in the system authentication. Thus I
Dan> don't think you can drop the checking for 4) since the user may
Dan> not be able to shut the system down.

I agree. I assume there would be fewer upgrade issues to consider
here, since sqlAuthorization is new in 10.2. I also don't think we
want to base enforcement of a database level action on whether
authentication is db local or system wide?

Seems there are more than Rick's three toggle dimensions in this space
that matter: system vs db level authentication, and readOnly vs
fullAccess connection authorization :)

> 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.

View raw message