From: | August Zajonc <augustz(at)augustz(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <Robert(dot)Haas(at)dyntek(dot)com>, Joris Dobbelsteen <Joris(at)familiedobbelsteen(dot)nl>, Golden Liu <goldenliu(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Google SoC: column-level privilege subsystem |
Date: | 2007-04-25 05:56:27 |
Message-ID: | 462EED8B.4000004@augustz.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Robert Haas" <Robert(dot)Haas(at)dyntek(dot)com> writes:
> ...
>
>>> IF this will be implemented as suggested here, it will become
>>> extremely counter-intuitive.
>>>
> ...
>
>> You could solve this by having explicit positive and negative ACLs, i.e.
>> your permissions for a particular column are:
>>
>
> Uh, wait a moment, people. The proposed project is to implement a
> capability that is fully, 100% specified by the SQL standard. There
> is zero scope for API invention here. You read the spec, you do
> what it says.
>
>
I did read the spec. My suggestion still stands. Because this is a
non-standard construct in the security world (which generally does &&
when combining attributes) the fact that revoking permissions on a
column does nothing unless table exist deserves being documented.
I couldn't find the detail on the rest in the spec (what section is that
in?) but I know Oracle allows inserts to happen if the columns without
privilege are null or have a default value. Am I missing something
obvious in the spec that describes this explicitly?
- August
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Drake | 2007-04-25 06:48:30 | Re: tsearch2 in 8.3 |
Previous Message | Tom Lane | 2007-04-25 05:37:59 | Re: Google SoC: column-level privilege subsystem |