Re: Limiting the operations that client-side code can perform upon its database backend's artifacts

Bryn Llewellyn <bryn(at)yugabyte(dot)com> writes:
> rjuju123(at)gmail(dot)com wrote:
>> I'm not convinced... that the authorization system can prevent an untrusted user with a direct SQL access from actually hurting you.

> What do you mean by "untrusted"? Any person who is given the credentials
> to start a database session is trusted—even a person who can connect as
> a superuser and do untold harm. So focus on a person who has the
> credentials to connect as "client" in my example. But imagine a design
> that exposes functionality to "client" sessions exclusively through a
> carefully designed and implemented API that's expressed exclusively with
> user-defined functions and procedures.

Sure. That is called an application server. What we are is a SQL server,
and that means that the API is SQL commands, and the authorization model
is what the SQL spec says it is. (Well, okay, there's some discrepancies
between the letter of the spec and what we actually do. But my main
point here is that any session authenticated as user X has the same
privileges as any other session authenticated as user X, so there is
not a lot of point in user X mounting defenses against user X.)

So I think the concerns you're expressing here would be better addressed
at the next level up the stack.

regards, tom lane