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

Re: How to get SE-PostgreSQL acceptable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joshua Brindle <method(at)manicmethod(dot)com>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to get SE-PostgreSQL acceptable
Date: 2009-01-28 23:57:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Joshua Brindle <method(at)manicmethod(dot)com> writes:
> In reality it isn't, unless postgres won't mind thousands of
> partitions being made. In the military/gov implementations BLP lets
> you have hierarchical levels and non-hierarchical categories. Since I
> linked to an article about it upthread I assumed everyone
> participating was familiar but perhaps not. Typically there are 3
> levels, unclass, secret, top secret. In addition to those 3 levels
> there may be a few, hundreds or even thousands of categories. Those
> categories apply to each of the levels so if you are using 1000
> categories you have 3*1000 possible BLP labels. On top of that SELinux
> has users, roles and types, which are all also multiplied.

Hmm.  If that's the expected application environment then the patch as
proposed has fatal performance problems anyway, for lack of a way to
get rid of no-longer-referenced pg_security rows.  We had been led to
understand that there wouldn't be all that many distinct labels in use,
but this seems to imply that there are going to be $bignum of them.
That changes pg_security leakage from a can-live-with-for-first-cut
issue to a must-fix-to-be-credible issue.

(Just for context, thousands of partitions isn't practical with our
current implementation, but might be in the future.)

> Nonetheless, this conversation seems moot now that Tom has walled off
> and won't even discuss row-level access controls.

You realize, I trust, that I don't have the only vote around here.
But I am convinced that the row-level-security aspect of this proposal
is far less than fully baked, and isn't going to become so in the time
frame available for 8.4.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-01-29 00:03:21
Subject: Re: How to get SE-PostgreSQL acceptable
Previous:From: Andrew DunstanDate: 2009-01-28 23:46:12
Subject: Re: How to get SE-PostgreSQL acceptable

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