From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) |
Date: | 2008-11-21 04:53:37 |
Message-ID: | 200811210453.mAL4rb929109@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2008-11-21 05:07:03 | Re: SSL configure patch: review |
Previous Message | Philip Warner | 2008-11-21 04:45:46 | Opening a recovering DB in for read-only access? |