Bryn Llewellyn <bryn@xxxxxxxxxxxx> writes: > rjuju123@xxxxxxxxx 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
