Re: Hot to restrict access to subset of data

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

In response to

Responses

Browse pgsql-general by date

  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