Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>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.
>>
>>
>
>You're wrong here. Just ask Alex, his opinion has much more value than ours.
>
>
>
>>There is no precedent for any SQL statement specifying the security
>>context in which it executes. Let's not create one.
>>
>>
>
>Imagine we have user A executing a procedure created by user B. This
>procedure creates a table via EXEC STMT. Who's expected to become an owner
>of this new table?
>
>
>
>

We've been talking about two schemes, the existing scheme where the
execute statement has only user privileges, and a proposed scheme where
the execute statement has the union of procedure and user privileges.
The difference is that in the proposed scheme, the dynamic statement has
the same potentially enhanced privileges of the procedure as do any
static SQL statements.

I have no idea where the idea that a procedure should execute in its
owner's security context and identity came from. As far as I can tell
it wasn't part of the original execute statement semantics, it isn't
part of the proposal, it isn't part of Firebird 2 or predecessors, it
isn't part of SQL, and it basically destroys SQL security.

The basis for the existing security mechanism is that users have rights
based on their login account and role. For normal operations, these
rights apply. View and procedures, however, can be granted additional
rights on the basis that they are considered, within specific limits,
trusted code. The idea that a procedure would execute with the rights
and identity of its creator breaks all this, requiring extremely careful
access control to every stored procedure on the system. It's the
logical equivalent to giving any executable the access rights of the guy
who linked it.

Lets get back to your question. User B creates a procedure P that
contains code to create new table dynamically. User A calls P to create
table T. Who owns T? A does unless P does something to change the
ownership. Furthermore, the rights to T will be exactly the same as if
A had created it directly unless P does something to the contrary.




[Non-text portions of this message have been removed]