Bruce Momjian wrote:
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?
When SE-PostgreSQL binary fetch a tuple without its security attribute,
it considers the tuple has an alternative one called as "unlabeled_t".
This behavior is same as when we mount an unlabled filesystem on SELinux
system.
> What happens if I load a non-SE-Linux data dump into a SE-Linux binary?
> Do I lose my security settings?
It is same as normal INSERT case. When user gives a data without specific
security context, SE-PostgreSQL assigns it a default security context.
In the default security policy, it is "sepgsql_table_t".
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.
It is just an idea. If Row-level ACL feature is *hardcoded* (not a guest
of PGACE), is it considerable a hidden attribute typed as "aclitem[]"?
Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
