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 <[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
