Discussion:
[ADMIN] Giving postgres roles 'sudo'-like access
(too old to reply)
Mario Splivalo
2011-12-19 18:04:13 UTC
Permalink
I need to have postgres role to be able to cancel queries run by that
same role.

I know that I can kill the client connection that started the query, but
I also need to have that role connect to postgres and kill some of it's
running queries.

It's on postgres 9.1.1, running on Debian Squeeze.

One idea that comes to mind is to have a special user account on the box
which would have sudo privileges to the script which will issue 'sh
postgres -c 'psql -c "select pg_cancel_backend(<pid>)"', but before that
run checks that <pid> is actually owned by correct role, etc, etc. But,
all that seems very fishy.

Has anyone had similar requests, and maybe solved them somehow?

Mario
--
Sent via pgsql-admin mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Craig James
2011-12-19 18:46:53 UTC
Permalink
Post by Mario Splivalo
I need to have postgres role to be able to cancel queries run by that
same role.
I know that I can kill the client connection that started the query, but
I also need to have that role connect to postgres and kill some of it's
running queries.
It's on postgres 9.1.1, running on Debian Squeeze.
One idea that comes to mind is to have a special user account on the box
which would have sudo privileges to the script which will issue 'sh
postgres -c 'psql -c "select pg_cancel_backend(<pid>)"', but before that
run checks that<pid> is actually owned by correct role, etc, etc. But,
all that seems very fishy.
Has anyone had similar requests, and maybe solved them somehow?
Yes.

First of all, you really don't want to do this. If there's any other way, find it.

In our case, we use a third-party library that sometimes gets stuck on problems that would take a virtually infinite time to solve, and for reasons having to do with NP-complete theory, you can't easily detect them ahead of time. So....

Backend Postgres processes run as the Postgres user, so they have permission to kill each other. You write an add-on function that just kills a process:

select my_kill_backend(pid);

Naturally, this is very dangerous. There are all sorts of security implications. You want to use signal 2 or 15, not 9. And so forth.

Craig
--
Sent via pgsql-admin mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Mario Splivalo
2011-12-20 08:14:25 UTC
Permalink
Post by Craig James
Backend Postgres processes run as the Postgres user, so they have
permission to kill each other. You write an add-on function that just
select my_kill_backend(pid);
Naturally, this is very dangerous. There are all sorts of security
implications. You want to use signal 2 or 15, not 9. And so forth.
That 'my_kill_backend' actually calls kill, not pg_cancel/terminate_backend?

I'm thinking into creating this function, and granting particular role
access to it, and then make sure, in the function, that it can kill only
processes 'owned' by that role.

Mario
--
Sent via pgsql-admin mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Greg Smith
2011-12-20 13:49:28 UTC
Permalink
Post by Mario Splivalo
I need to have postgres role to be able to cancel queries run by that
same role.
This feature is close to commit as a new one for PostgreSQL 9.2:
http://archives.postgresql.org/message-id/***@2ndQuadrant.com
http://archives.postgresql.org/pgsql-hackers/2011-12/msg00822.php

You might use some of that code and make your own pg_cancel_backend-like
function that loads into the database.
--
Greg Smith 2ndQuadrant US ***@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-admin mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Loading...