Skip site navigation (1) Skip section navigation (2)

Re: Foreign keys breaks tables permissions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <wieck(at)debis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: Foreign keys breaks tables permissions
Date: 2000-05-18 23:17:06
Message-ID: 25918.958691826@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-sql
Resurrecting a bug report from mid-April:

wieck(at)debis(dot)com (Jan Wieck) writes:
>> If one does:
>> 
>> [...]
>> grant select on master to a_user;
>> grant select, insert, update, delete on detail to a_user;
>> 
>> then if login as "a_user" and does:
>> 
>> insert into detail (id, master_id) values (1, 10);
>> 
>> this will result in: "ERROR:   master: Permission denied".
>> 
>> This seems a bug to me ? Isn't it ?

> Outch,

>     yes,  we  missed  something  here.  Peter,  you  said  you'll
>     probably work  on  the  ACL  stuff  after  7.0.  We  need  to
>     coordinate that work with the function manager redesign to go
>     for SETUID triggers and functions.

I looked at this some more because people were complaining that it
was still broken in 7.0.  AFAICT, it's got nothing to do with SETUID
triggers or anything so hairy, it's just a question of what permissions
we think ought to be required for which actions.  The issue is very
simple: the RI insert trigger doesn't do a SELECT on the master table,
it does a SELECT FOR UPDATE --- and execMain.c thinks that that should
require UPDATE access rights to the master.

So, two questions:

1. Why is RI_FKey_check() using SELECT FOR UPDATE and not plain SELECT?

2. What permissions should SELECT FOR UPDATE require?

If the existing code is correct on both these points, then I think the
answer is that there is no bug: updating a table that has a foreign
key reference will require update rights on the master as well.  I would
rather conclude that one of these two points is wrong...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Cary O'BrienDate: 2000-05-18 23:18:43
Subject: Re: LONG: How to migrate data from MS-SQL7 to PostgreSQL 7.0
Previous:From: Alfred PerlsteinDate: 2000-05-18 19:16:19
Subject: Re: The New Slashdot Setup (includes MySql server)

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2000-05-19 02:58:32
Subject: Re: [SQL] Foreign keys breaks tables permissions
Previous:From: Tom LaneDate: 2000-05-16 22:46:24
Subject: Re: Small bug with numeric in 7.0 (also in 6.5.3)

pgsql-sql by date

Next:From: Peter EisentrautDate: 2000-05-18 23:50:18
Subject: Re: Question about databases in alternate locations...
Previous:From: mkresseDate: 2000-05-18 22:19:36
Subject: Re: Foreign keys and access privileges

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group