From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Force pg_hba.conf user with LDAP |
Date: | 2016-08-01 20:44:40 |
Message-ID: | 15137.1470084280@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
John McKown <john(dot)archie(dot)mckown(at)gmail(dot)com> writes:
>Perhaps what is necessary is something akin to the UNIX "sudo" facility.
> That is, an SQL statement prefix which, if used, runs the given SQL
> statement as a PG superuser. You then GRANT(?) authority to that facility
> like you would to a table or database or ... . E.g. GRANT SUDO TO SOMEBODY;
> who could then do SUDO some other SQL statement; and that SQL statement
> would be done as if the PG user was a superuser.
You can already achieve effects of that sort with a security definer
function, eg
begin;
create function sudo(text) returns void as
$$begin execute $1; end$$ language plpgsql security definer;
revoke all on function sudo(text) from public;
grant execute on function sudo(text) to trusted_users;
commit;
(You have to work a bit harder if you want to be able to return query
results, but it's doable.)
The main benefit of approaching things this way is it doesn't have to
be all-or-nothing: the gating function can apply checks on what it
will allow.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2016-08-01 21:21:19 | Re: Force pg_hba.conf user with LDAP |
Previous Message | John McKown | 2016-08-01 20:32:31 | Re: Force pg_hba.conf user with LDAP |