Another point to keep in mind is that by default, execute privilege is granted to PUBLIC for newly created functions (see GRANT for more information). Frequently you will wish to restrict use of a security definer function to only some users. To do that, you must revoke the default PUBLIC privileges and then grant execute privilege selectively.
This goes wrong with pgAdmin 1.14.2. Consider this test case, executed as superuser postgres:
CREATE OR REPLACE FUNCTION foo () RETURNS void AS $BODY$ BEGIN PERFORM 1; END; $BODY$ LANGUAGE plpgsql VOLATILE SECURITY DEFINER; ALTER FUNCTION foo() SET search_path=public, pg_temp; REVOKE ALL ON FUNCTION foo() FROM PUBLIC; GRANT EXECUTE ON FUNCTION foo() TO ief;
The reverse engineered SQL looks like this
-- Function: foo()
-- DROP FUNCTION foo();
CREATE OR REPLACE FUNCTION foo() RETURNS void AS $BODY$
BEGIN PERFORM 1; END; $BODY$ LANGUAGE plpgsql VOLATILE SECURITY DEFINER COST 100; ALTER FUNCTION foo() SET search_path=public, pg_temp;
ALTER FUNCTION foo() OWNER TO postgres; GRANT EXECUTE ON FUNCTION foo() TO postgres; GRANT EXECUTE ON FUNCTION foo() TO ief;
The REVOKE statement is missing, which is a serious security hazard. A recreated function will be open to the the public.
