Vlad Horsun wrote:

>>An underlying question is whether security exists to protect the
>>careless from themselves? A developer who allows procedures to execute
>>arbitrary SQL in an application with sophisticated security rules is
>>careless at best. Or do we want to make it possible to build systems
>>that use all the capabilities of the system together?
>>
>>
>
> I think both security principles for EXECUTE STATEMENT have rights
>for existence. We can extend syntax of EXECUTE STATEMENT for example :
>
>EXECUTE STATEMENT ... [WITH {USER | OWNER | PROCEDURE} RIGHTS]
>
>
>

The privileges applied in the original implementation were dictated by
its implementation -- it looped back into the engine with a separate
attachment, and had no context for the procedure privileges. While I
think that the pragmatics justified an inelegant solution, we really
should recognize that it was a "hack", and under different
circumstances, no one would have implement a situation where an "execute
statement" would ever have a security context different than the code
that executed it.

That being the case, I think the right thing to do is breath a sigh of
relief that unfortunate compromise will shortly be in our past.

There is no precedent for any SQL statement specifying the security
context in which it executes. Let's not create one.

We have too many options. Let's find some to get rid of rather than
adding more. A friend, at the time supervisor for VAX DBMS, described
the product as having "few options but many defaults." That sort of
befuddlement is the software gods telling you that you have too many
options.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376