Please consider SELinux/SE-PostgreSQL requires various kind of objects
(including database objects) to be labeled properly at the initial state.
If it allows clients to turn on row-level security feature, it means many
"unlabeled" tuples appear suddenly. In generally, these have to be labeled
before the system get being available.
I was thinking more about people are using the SQL-level row
permissions. Are they going to want it for all tables for all
databases, or not at all?
We don't have a reason why the SQL-level row permissions should be toggled
in global only. It it designed based on DAC policy, so it is quite natural
to be controled by owner of resources.
(However, it is not implemented yet.)
Actually, you called it "sepostgresql_mode", SE*, but how are we going
to control the SQL-level row permissions? Are we using this name? I
didn't think so because it seems so associated withe SE-Linux, and if
not, how would one say whether a table has SQL-level row permissions?
A new GUC variable of "row_acl_is_enabled" allows us to toggle the SQL-level
row permission feature, when the binary is built with "--enable-row-acl".
In this case, the "sepostgresql_*" are enclosed by #ifdef HAVE_SELINUX, so
these are not available.
On a related note, KaiGai, you are now starting the long road of getting
feedback with the ultimate goal of getting your patch into CVS. I will
warn you that there is often much work during this stage, and it might
stretch into January as we request adjustments, but ultimately your
feature and Postgres will be better for it. Thanks for sticking with
it.
Don't worry, I'm be available for the works, and give a lot for inclusion
of the feature at v8.4.
Great. Sometimes these bold additions can require perhaps thirty
changes before they are added to CVS, I am afraid to say. It can be a
painful part of open source development, even though in the end it is
worth it. (While it is happening, it doesn't seem very useful.)
s/painful/dynamic/g :-)
If you can ready to post some of comments, earlier is happier for me.
It is unclear for me when the CommtiFest:Nov is finished, but it is sure
we don't have enough days.
In my guess, I'll be able to complete to put a flag within TupleDesc to
control security field of HeapTupleHeader by tomorrow. And I have a plan
to check its behavior in this weekend before merge them into my tree.
Thanks,
--
OSS Platform Development Division, NEC
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
