From: | Garry Chen <gc92(at)cornell(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Column level security question |
Date: | 2017-06-21 16:46:56 |
Message-ID: | CY1PR0401MB10514BF5E886A87F71E3BBBDDADA0@CY1PR0401MB1051.namprd04.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Hi Tom,
The column or columns can just return null for the non-authorized user then there is not SQL semantics issue.
Garry
-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, June 21, 2017 12:27 PM
To: Garry Chen <gc92(at)cornell(dot)edu>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] Column level security question
Garry Chen <gc92(at)cornell(dot)edu> writes:
> For example: a function that only allow deptno=30 or resp=10 to see column named 'sale' and 'card_num' and a policy that applied to the table that can carry out the function. So only user in deptno 30 or responsibility level equal to 10 can see column named 'sale' and 'card_num' without using role. Such that the security can be relied on the data owner not the DBA.
I think you'd be better off to think of a way to express this through grantable privileges, perhaps with some intermediate views that different user populations are allowed to access. It's really hard to think of a way that columns could be dynamically allowed or not allowed without breaking SQL semantics pretty thoroughly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-22 14:52:08 | Re: pl/pgsql and returns timestamp type |
Previous Message | David G. Johnston | 2017-06-21 16:27:58 | Re: Column level security question |