>> ... which presumably wouldn't involve any added dependency on outside
>> code.
>> For people who are already using SELinux or Trusted Solaris, making the
>> database dependent on that infrastructure might be seen as a plus, but
>> I'm not sure the rest of the world would be pleased.
>
> Yes, I was thinking that this should be a compile-time option with a lot
> of warnings in the Docs.
Yes, those facilities are not enabled without '--enable-selinux' compile-time
option. It's a bit unclear for me what means the "a lot of warnings the Docs".
> Give the team some credit, though; they've managed to come up with a
> system that integrates OS-level ACLs for both SElinux and TxSol, are not
> asking us to incorporate two different sets, and are coming to us with a
> serious proposal that has a lot of work behind it. Please don't blow
> them off like they were undergrads submitting a semester project. If
> they need to come back after 8.3 beta so we can properly pay attention
> to the proposal, then say so.
I don't hurry to merge those facilities regardless.
(8.3 is already feature frozen, as announced earlier.)
As I mentioned at first, the purpose of this discussion is to obtain
any feedbacks from PostgreSQL community, for our development.
I believe it also helps SE- stuff to be merged in the later version
of PostgreSQL.
> There are also
>> some interesting questions about SQL spec compliance and whether a
>> database that silently hides some rows from you will give semantically
>> consistent results.
>
> Yeah -- that's a potentially serious issue; KaiGai, have you looked into
> it?
Yes, I consider the policy to filter any violated tuple looks consistently.
The policy enforces any tuple has to be filtered before using them, and
it helps that computational processes don't get any effect from them.
But proving innocence is generally hard task.
At first, I want to know what points are you worried about the most.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>