Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +