Mladen Gogala <gogala.mladen@xxxxxxxxx> 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"—and where 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
