KaiGai Kohei wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >> KaiGai Kohei <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
