Re: Column level security question

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

In response to

Browse pgsql-novice by date

  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