Satheesh Bandaram wrote: > > > Daniel John Debrunner wrote: > >>Satheesh Bandaram wrote: >> >> >>>Until these system privileges are ready, current proposal limits >>>accesses that would cause forward compatibility issues. >>> >>> >> >>Except that it doesn't, I believe we need additional restrictions on >>table and routine creation. >> >> > In sqlStandard mode, the proposal only allows for creating tables and > routines in their own Schema and no where else. I thought this is too > restrictive already :-) , but makes sense that unless someone grants > ability to create tables in their schema, Derby shouldn't allow that. > Currently there is no way to grant privilege to create tables... > > What future scenario do you see where schema owners don't have ability > to create tables or routines in their own schema, by default? It may be > possible that Derby would allow granting/revoking table or routine > privileges in the future, but default behavior for a schema owner would > be to have this privilege by default?
I looked at some other databases (Oracle, DB2, Postgres) and the typical model is to require a database level privilege to create tables or call an external routine. Create table I could possibly go either way on, but if we followed the de-facto standard model of other databases then we need a database level privilege. Creating an external routine would have all sorts of security concerns for a database owner, it's allowing a remote user to execute code on their system. Dan. >>>Current legacy >>>authorization model is not compatible with standard model or what Derby >>>might really want to support, but at the same time, we can't drop >>>support for it because of existing applications. >>> >>> >> >>I'm not sure why "legacy" mode keeps being dragged into this discussion, >>or why folks see it as "not compatible". >> > If current or legacy mode is compatible with sqlStandard mode, would > there be a need to add new property, derby.database.sqlAuthorization? I > understand going forward defaultConnectionMode can be seen as compatible > with standard model as additional layer of authorization, but I see > there is a break from 10.1 model to 10.2. > >> I see it as compatible, it's an >>additional layer of authorization at the incoming connection level. >> >> - full-access - Access limited to granted privs. >> >> > The way I see it, Derby is essentially changing full-access meaning... > from "read/write access to every object in the database" to "read/write > access to objects owned or been granted limited access to" in > sqlStandard mode. This would force existing applications to change to > adapt to sqlStandard mode, right? If so, we have an incompatibility. I think we are in agreement, but talking about different things. Introducing grant/revoke causes behaviour incompatible (when enabled) with previous releases. The connection based authorization model (noAccess, readOnly or full) by itself is not incompatible with grant/revoke. Dan.
