From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Samuel Thoraval <samuel(dot)thoraval(at)librophyt(dot)com> |
Cc: | Andrus Moor <eetasoft(at)online(dot)ee>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Hot to restrict access to subset of data |
Date: | 2005-07-19 15:22:58 |
Message-ID: | 24704.1121786578@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Samuel Thoraval <samuel(dot)thoraval(at)librophyt(dot)com> writes:
> I have been trying this example not executing the GRANT UPDATE statement
> at first to check that user b doesn't have the right to update. The
> problem is that even though B was not granted the update privilege, it
> worked anyway. In other words, simply executing " GRANT SELECT ON
> b.document TO b;" is sufficient for user b to be able to update the
> view, and thus the public.document table for DocumentType = Z.
> Anybody has an explanation to this ?
What PG version are you running? This item from the 7.3.6 release notes
seems relevant:
Revert erroneous changes in rule permissions checking
A patch applied in 7.3.3 to fix a corner case in rule permissions
checks turns out to have disabled rule-related permissions checks
in many not-so-corner cases. This would for example allow users to
insert into views they weren't supposed to have permission to
insert into. We have therefore reverted the 7.3.3 patch. The
original bug will be fixed in 8.0.
The first couple of 7.4.x releases had the bug too.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-19 15:25:52 | Re: index row size exceeds btree maximum, 2713 - |
Previous Message | Tom Lane | 2005-07-19 15:19:06 | Re: Old question - failed to find conversion function from |