KaiGai Kohei wrote: > >> 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.)
Yes, that was my question --- how will SQL-level row permissions be controlled by the user. > > 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". I assumed we would always enable SQL-level row permissions. Why would it be a compile-time option? > In this case, the "sepostgresql_*" are enclosed by #ifdef HAVE_SELINUX, so > these are not available. Right. > >>> 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 :-) That's looking on the bright side of things. :-) > If you can ready to post some of comments, earlier is happier for me. My guess is we will continue to send you ideas. > It is unclear for me when the CommtiFest:Nov is finished, but it is sure > we don't have enough days. This is the last commit fest for 8.4 so it will probably go well into December, perhaps January. > 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. Nice. I will look over your newest version as soon as I can. -- 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
