[ZODB-Dev] RelStorage on Oracle RAC (doing now)

[Darryl Dixon - Winterhouse Consulting]

Hi Shane!

Thanks for your very helpful input :)

[...snip...]

> As a result of this choice, you had to do this instead of following the
> RelStorage documentation:
>
>> GRANT EXECUTE ON DBMS_LOCK TO zope;
>

Yes :-/

I spoke with the Oracle DBA here at some length and he went and double
checked his assumptions on this one. Basically, here's what it boils down
to from his perspective:
1) Stuff in SYS is not retained during a full database export/import, so
he is keener to see the package in the relevant schema
2) EXECUTE on DBMS_LOCK does indeed allow the user to attempt to acquire
other arbitrary user/application lock objects inside the database. He
feels (and in our situation I concur) that the risk here is very low; an
attack would require:
a) compromise of the zope database user, and
b) knowledge a priori of the id of a lock to be acquired from elsewhere in
the DB. Bearing in mind that these are user/application locks (like
semaphores), not locks which are fundamental to the operation of
Oracle-the-Database itself.

[...snip...]

> Here are some reasonable choices:
>
> 1) Leave it as-is and explain in the RelStorage docs why you should not
> change it.
>
> 2) Assume the Oracle security risk is insignificant (or nonexistent) and
> have everyone "GRANT EXECUTE ON DBMS_LOCK TO zope".  This would make
> RelStorage slightly simpler and faster.  I'm not opposed to that.

I'm ambivalent on either of these. I agree 11g would be nicer (we're
10.2.0.4 currently ;). We are basically committed here to maintaining it
as the DBA has required, so we will work in no matter what :)

> I don't want to make the choice of how to use DBMS_LOCK configurable.  I
> want everyone to use DBMS_LOCK the same way, whatever that way is going
> to be, to minimize support costs.

Sure, that makes sense to me.

> FWIW, I believe that DBMS_LOCK doesn't really have any security risks.
> Instead, I think its API is broken, so Oracle silently discourages its
> use.  If there were an alternative that works in 10g, we would use that
> instead.  We can't use table locks because the WAIT keyword was not
> added to the LOCK TABLE statement until release 11g.
>
> One we sort this out, we can make a final release of RelStorage 1.4.

We're happy for RelStorage to go either direction. If necessary we will
simply maintain our brief hotfix. Our only request would be that if it
stays where it is (in SYS), then it would be very nice if he package name
string was defined in a config.py variable or similar (eg,
relstorage.config.RELSTORAGE_UTIL = "sys...."). At least that way we can
hotfix only the string, rather than the function it is embedded in :)

regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com