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