On 2/21/06, Satheesh Bandaram <[EMAIL PROTECTED]> 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 need to check again and I thought object creation privileges were granted to some schema owner if that schema had been created explictly with the CREATE SCHEMA AUTHORIZATION DDL. > > 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. > Agreed - this additional layer has to be flagged in order to be turned on with its new semantics, no? I thought we had that new property (derby.database.sqlAuthorization) for that reason (and it can still be a layer on top of legacy) > 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. > That is correct. Once sqlStandard is enabled then legacy defined privileges become more like (specific) Roles for some users to be granted too - that's the way I see it. > Satheesh > >
