db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2264) Restrict shutdown, upgrade, and encryption powers to the database owner
Date Mon, 05 Feb 2007 16:31:05 GMT

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

Rick Hillegas commented on DERBY-2264:
--------------------------------------

Hi Dag,

Here's a long preamble about our security model and then a brief discussion of your specific
question. We seem to have 3 independent toggles for controlling Derby security:

A) Whether Java Security is on.

B) Whether user authentication is on.

C) Whether SQL authorization is on.

That gives rise to 8 security states, not all of which makes sense to me. Here they are, expressed
in terms of (A, B, C):

1) (off, off, off). This is the maximally unsecure configuration. It seems like a sensible
out-of-the-box default for embedded apps.

2) (off, off, on). Turning authorization on but turning authentication off doesn't make sense
to me. We raise a warning when the customer does this, but we let them do it, nonetheless.

3) (off, on, off). I think this is supported because we added GRANT/REVOKE long after we added
user authentication. I see limited use for this configuration.

4) (off, on, on). This case may be useful for customers who want GRANT/REVOKE protections
but don't want the performance drag imposed by Java security. I don't know how significant
that drag is on a Derby engine which has reached steady-state. That's an interesting experiment
to run.

5) (on, off, off). This might be useful for Derby-powered apps which are downloaded into a
browser.

6) (on, off, on). Like (2), this doesn't make much sense to me.

7) (on, on, off). Like (3), this doesn't make much sense to me either. However, I think we
are proposing this as our secure-by-default server configuration. I think we've ended up with
this as a default for the same reason that we support configuration (3): this eases the upgrade
problem for legacy applications.

8) (on, on, on) This is the maximally secure configuration. It makes more sense to me as the
out-of-the-box default for the network server.

I can imagine this is a bit perplexing to customers. For my money, (1) and (8) look like two
distinguished states whose semantics are very clear. Everything in-between is a little muddy

Now on to your specific question. In terms of enforcing the database-shutdown power, the only
settings which make sense to me are (7) and (8).  That is because it seems odd to me to let
an authenticated user shutdown the whole engine but not a single database.


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


Mime
View raw message