Mladen Gogala <gogala.mladen@gmail.com> writes:
> ... This doesn't look like a big problem because
> applications usually don't contain code for killing other user's
> sessions. I am not sure that GTA is running on top of Postgres database.
Yeah, I meant to comment on that further but forgot. I don't
particularly buy the premise that it's useful to prohibit a session
belonging to user X from killing another session belonging to user X.
In the end, the main point of a database is to store your data.
Therefore, if you don't trust another session that is running as
your userID, you have already lost. That session can drop your
tables, or corrupt the data in those tables to an arbitrary extent,
and the SQL permissions system will not squawk even feebly. Under
any reasonable understanding of the goals of a DB, those consequences
are far worse than killing a session. So if you're not happy with
this hazard, you should not be accepting the idea that actors you
don't trust are allowed to submit queries under the same userID
as you. And if you're using a client-side software stack that
forces that situation on you, it's time to look for another one.
Or in other words, I flatly reject the claim that this:
>>> It's common to design a three tier app so that the middle tier always authorizes as just a single role—say,
"client"—andwhere the operations that "client" can perform are limited as the overall design specifies.
is in any way sane or secure. There is not very much that the
database server can do to clean up after insecure client-side stacks.
regards, tom lane
