db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Question about grant/revoke
Date Tue, 03 Apr 2007 13:13:09 GMT
While working on re-using resultsets (DERBY-827) I've discovered that
calls to 

getLanguageConnectionContext().getAuthorizer().authorize(this , 1);

have been added in places that I don't think are compatible with
re-using result sets.

One example is the following decompiled byte code fragment which shows
that for prepared statements authorization will be done on the first
execution, only (this is WITH the DERBY-827 patch applied).

    public ResultSet execute()
		throws StandardException
    {
         throwIfClosed("execute");
         startExecution();
         BaseActivation.reinitializeQualifiers(e2);
         return ((resultSet == null) ? fillResultSet() : resultSet);
         // Oops, will not call fillResultSet() on later executions
    }


    private ResultSet fillResultSet()
		throws StandardException
    {
         getLanguageConnectionContext().getAuthorizer().authorize(this , 1);
         // Problem - can't check authorization here, will not get called when
         // ps is re-executed

         return (getResultSetFactory().getScrollInsensitiveResultSet(getResultSetFactory().getIndexRowToBaseRowResultSet((long)960
, 5 , getResultSetFactory().getTableScanResultSet(this , (long)977 , 7 , getMethod("e0") ,
2 , getMethod("e1") , 1 , null , -1 , true , e2 , "T1" , null , "SQL070402062141340" , true
, false , -1 , -1 , 6 , false , 0 , true , 1.0 , 5.1195) , getMethod("e2") , 1 , "T1" , 1
, 2 , 3 , 4 , null , false , 1.0 , 5.1195) , this , 0 , 2 , getScrollable() , 1.0 , 5.1195));
    }

This causes failures in derbyall when running with the DERBY-827 patch.


There is also the following code in GenericResultSetFactory

	public ResultSet getDDLResultSet(Activation activation)
					throws StandardException
	{
		getAuthorizer(activation).authorize(activation, Authorizer.SQL_DDL_OP);
		return getMiscResultSet( activation);
        }

which checks authorization when the DDL/Misc result set is created,
and not when it is opened.

I've not seen a failure caused by this, but I suspect it is a problem.

Do the grant/revoke experts have an opinion about how to fix this? 

I'm thinking that the byte code could be changed so that authorization
is done in execute() rather than fillResultSet(), and that the
DDL/Misc check could be deferred to open(). Will that work?

-- 
dt

Mime
View raw message