From: | "Mark Diener" <md(at)realmwireless(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #1874: Non-Execute Privileges enforced on grant |
Date: | 2005-09-10 08:33:15 |
Message-ID: | 20050910083315.43380F0B10@svr2.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged online:
Bug reference: 1874
Logged by: Mark Diener
Email address: md(at)realmwireless(dot)com
PostgreSQL version: 8.03
Operating system: linux-i686
Description: Non-Execute Privileges enforced on grant
Details:
It seems the EXECUTE privilege is not the only privilege that is being
checked during the execution of a PL/psql procedure language/function.
Only a superuser can execute non-trusted languages like python thus making
the python language unusable for average user. Only for superusers. What
happens when you want the python stored procedures to implement a layer of
security for standard users?
Then the pl/SQL language enforces SELECT/UPDATE/INSERT privileges on tables.
It would appear intuitive that only the EXECUTE privilege should be
evaluated when a stored procedure executes. By default, all superuser and
owner privileges should be allowed except for the EXECUTE privilege.
What happens when you want the pg/SQL stored procedures to implement a layer
of security for standard users and you don't want general users to have
select/update/insert privilege? It is not an option to skip the select SQL
statement within stored procedures.
From | Date | Subject | |
---|---|---|---|
Next Message | Byron | 2005-09-10 16:46:44 | BUG #1875: Function parameter names clash with table column names |
Previous Message | Lee Benson | 2005-09-10 04:52:08 | BUG #1873: "Invalid username specified" during install |