KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> >>> However, the toggle of row-level security feature should be controled
> >>> via a GUC option, not a discretionary option.
> >>> I'll add a "sepostgresql_row_level" option defined as bool to control
> >>> it on start up time.
> >> This sounds similar to BSD capability were certain security settings can
> >> only be changed in single-user mode.
> >
> > Actually, an interesting idea would be to allow "sepostgresql_row_level"
> > to be turned on, but not off. That means if it was turned on in
> > postgresql.conf, it could not be turned off, but if it is off in
> > postgresql.conf, it could be turned on via SET or via ALTER
> > USER/DATABASE; I think that would be a nice capability.
>
> I think the "sepostgresql_mode" and "sepostgresql_row_level" should not
> be toggled frequently.
>
> 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? I assumed they would want to be more
selective. I agree the SE-Linux users would probably not toggle it for
different objects and databases frequently.
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?
> > 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.)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +