... which presumably wouldn't involve any added dependency on outside
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
There are also
some interesting questions about SQL spec compliance and whether a
database that silently hides some rows from you will give semantically
Yeah -- that's a potentially serious issue; KaiGai, have you looked into
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.
KaiGai Kohei <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at