Re: Proposal of SE-PostgreSQL patches [try#2]

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Josh Berkus <josh(at)agliodbs(dot)com>, bruce(at)momjian(dot)us, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Subject: Re: Proposal of SE-PostgreSQL patches [try#2]
Date: 2008-07-07 15:39:57
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Am Donnerstag, 26. Juni 2008 schrieb KaiGai Kohei:
> The following patch set (r926) are updated one toward the latest CVS head,
> and contains some fixes in security policy and documentation.

OK, I have quickly read through these patches. They look very nice, so I am
optimistic we can get through this.

First of all, now would be a good time if someone out there really wants to
object to this feature in general. It will probably always be a niche
feature. But all the code is hidden behind ifdefs or other constructs that a
compiler can easily hide away (or we can make it so, at least).

Here is a presentation from PGCon on SE-PostgreSQL:

Are there any comments yet from the (Trusted)Solaris people that wanted to
evaluate this approach for compatibility with their approach?

In general, are we OK with the syntax CONTEXT = '...'? I would rather see
something like SECURITY CONTEXT '...'. There are a lot of contexts, after

This will also add a system column called security_context. I think that is

In the pg_dump patch:

spelling mistake "tuen on/off"

Evil coding style: if (strcmp(SELINUX_SYSATTR_NAME, security_sysattr_name)) --
compare the result with 0 please.

The above code appears to assume that security_sysattr_name never changes, but
then why do we need a GUC parameter to show it?

Might want to change the option name --enable-selinux to something
like --security-context.

In general, we might want to not name things selinux_* but instead
sepostgresql_* or security_* or security_context_*. Or maybe PGACE?

On the default policy:

Should this really be a contrib module? Considering that it would be a core
feature that is not really usable without a policy.

Please change all the sepgsql_* things to sepostgresql_*, considering that you
are using both already, so we shouldn't have both forms of names.


Looks good for a start, but we will probably want to write more later.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-07-07 15:58:45 Re: gsoc, text search selectivity and dllist enhancments
Previous Message Simon Riggs 2008-07-07 15:35:21 Re: deadlock_timeout