Re: Grant -revoke (464) and future backwards compat

[Satheesh Bandaram]

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? If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. 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. Satheesh