From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [EXAMPLE] Overly zealous security of schemas... |
Date: | 2003-04-26 21:17:45 |
Message-ID: | 18790.1051391865@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> Howdy. It looks as though the checks that allow for access to schemas
> doesn't check the correct permissions of the running user in that if a
> function is being run as the security definer, the schema checks still
> check the session_user. Am I missing the work around someplace or is
> this a bug?
It looks to me like the bug is not related to the use of a SECURITY
DEFINER function at all, but just to the use of foreign keys. The
RI triggers know they should setuid to the table owner for execution
of their generated queries --- but they fail to do so for parsing the
queries. So parse-time security checks (such as USAGE on schemas)
will fail.
I think you can make the same problem happen without a SECURITY DEFINER
function --- what you need is user A inserting into table B, which has
an FK reference to table C, which is in a schema that B's owner has
USAGE rights on but A doesn't. Would you try it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2003-04-26 21:36:03 | Re: [EXAMPLE] Overly zealous security of schemas... |
Previous Message | Peter Eisentraut | 2003-04-26 21:07:17 | Array access to type "name" |