Re: [PATCH] SE-PgSQL/tiny rev.2193

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Joshua Brindle <method(at)manicmethod(dot)com>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193
Date: 2009-07-21 22:38:35
Message-ID: 407d949e0907211538wb1e5cc5gbf65b8d085c9684@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle<method(at)manicmethod(dot)com> wrote:
> You also snipped the other scenario I had where row based access control
> isn't required but column level and stored procedure level are.

Well we already have column level and stored procedure privileges.

> I understand
> you already have column level access controls but it still goes back to how
> the user is accessing the data, as a top secret user who can read the column
> with full precision or as a secret user with precision removed via a trusted
> stored procedure.

Sure, and people do this every day already with postgres roles and privileges.

> The SELinux policy would have to give the stored procedure
> the ability to read the column and trust it to remove the necessary amount
> of precision.

Well the question is: Is the important feature of SEPostgres the
unification of the privilege model with every other piece of the
system in the SELinux policy? Or is that not the main thing and only
the row-level access security is interesting. None of the use cases
seem to put any emphasis on the unification of the security policy.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-21 23:25:52 Re: revised hstore patch
Previous Message Tom Lane 2009-07-21 22:34:16 Re: bytea vs. pg_dump