Skip site navigation (1) Skip section navigation (2)

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 15:13:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle<method(at)manicmethod(dot)com> wrote:
> Backing up from KaiGai's description a bit, basically what this is needed
> for is storing multilevel data in a single db instance.
> For example, you have people logging in from different classifications
> (unclass, secret, top secret, etc) and the data they put in is marked
> (labeled) with their classification label.

I'm beginning to wonder if we haven't gone about this all wrong. Every
time someone asks my question about use cases the only answers that
come back are about row-level security. Perhaps that's the only case
that really matters here.

If we provide a way to control access to database objects through
SELinux policies -- ie, one which is functionally equivalent to what
we have today but just allows administrators to control it in the same
place they control other SELinux system privileges, is that useful? Is
that something SE administrators want? Or are they happy to use
Postgres roles and grants and just want the finer row-level data
access controls?


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-21 15:17:29
Subject: Re: Sampling profiler updated
Previous:From: Alvaro HerreraDate: 2009-07-21 15:05:02
Subject: Re: navigation menu for documents

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group