KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> >>> Bruce Momjian wrote:
> >>>> I assume that could just be always enabled.
> >>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> >>> rest of enhanced security features (includes the row-level ACL) are
> >>> disabled automatically, as we discussed before.
> >> It seems like a pretty awful idea to have enabling sepostgres take away
> >> a feature that exists in the default build.
> >
> > Agreed.
>
> I don't agree. What is the reason why? It has been unclear for me.
>
> The PGACE security framework is designed to allow users to choose
> an enhanced security mechanism from some of provided options.
> (Currently, we have sepgsql and rowacl.)
> It is quite natural that one is disabled when the other is enabled.
>
> If a specific enhanced security mechanism has a privileged position,
> it should not be a guest of the security framwork, and be hardcoded
> like existing table-level database ACLs.
>
> Again, I don't oppose the Row-level ACLs to be the default selection.
> However, it should be a selectable option.
I understand, but imagine how this is going to interact for users. What
happens if I install an SE-Linux binary and point it at a /data
directory that was not created by SE-Linxu binary. How is the SE-Linux
binary going to interpret the security field? What happens if I load a
non-SE-Linux data dump into a SE-Linux binary? Do I lose my security
settings?
I am starting to think we should have two optional security fields, one
for SQL and one for SE-Linux. The big downside of that is that we are
back to the case of the having lots of SE-Linux-specific code to handle
that SE-Linux field, rather than reusing the SQL-row-level security
field.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +