From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | "Eugene E(dot)" <sad(at)bankir(dot)ru>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Permission to Select |
Date: | 2006-03-13 15:10:51 |
Message-ID: | 1142262651.857.77.camel@home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Mon, 2006-03-13 at 10:46 -0400, Alvaro Herrera wrote:
> Rod Taylor wrote:
>
> > By allowing the user a where clause you grant them select privileges.
> > You will find that delete works the same way.
> >
> > This is one of those times when per column permissions are useful. You
> > could grant them select access on the "name" column but not the "salary"
> > column.
>
> If I understand clearly, the patch he posted modified things so that if
> the user issued an UPDATE command, the SELECT permission was required as
> well. Thus a user with UPDATE privileges but no SELECT was not allowed
> to execute the UPDATE command.
Okay, I got it backward. The exclamation mark behind the first point
made me think it was an issue.
What information can be retrieved from a structure by being able to
update all rows? You possibly find the range of values (max/min via
integer overflow) but still would not know which tuple is associated
with which value.
I don't have a use-case for update but the delete / insert combination
is quite handy for doing data resets from a host which should not be
able to retrieve the interim states.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-03-13 15:27:27 | Re: Permission to Select |
Previous Message | Achilleus Mantzios | 2006-03-13 15:04:03 | Re: removing "not null" modifier |