| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Joshua Brindle <method(at)manicmethod(dot)com>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 8.4 release planning |
| Date: | 2009-01-28 22:44:06 |
| Message-ID: | 200901282244.n0SMi6i03928@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas wrote:
> > The flaw in that argument is that as you are doing it, the
> > de-optimization only happens on queries that actually need the behavior.
> > As the SEPostgres patch is constructed, the planner could *never* trust
> > an FK for optimization since it would have no way to know whether row
> > level permissions might be present (perhaps only for some rows) at
> > execution time. You could only get back the optimization in builds with
> > SEPostgres compiled out. That's pretty nasty, especially for packagers
> > who have to decide which build setting will displease fewer users.
>
> OK, I think I am starting to understand your concern now.
>
> My understanding of how the world works is SE-PostgreSQL would always
> be compiled in but could be turned off at run-time with a GUC. I know
> that the original design called for a compile-time switch, but
> everyone hated it and I am pretty sure KaiGai changed it. If he
> hasn't, he will. :-)
>
> There was also talk of having a table-level option to include/exclude
> the security ID (I'm not sure if it's currently implemented that way).
> Obviously that wouldn't be relevant for row-level MAC (because
> presumably you would need/want that turned on for all tables) but it
> would be very relevant for row-level DAC (because it's easy, at least
> for me, to imagine that you would only turn this on for a subset,
> possibly quite a small subset, of your tables where you knew that it
> was really needed).
>
> If, by default, we make sepostgresql disabled, MAC security IDs on
> newly created tables off, and DAC security IDs on newly created tables
> off, then the pain will be confined to people who explicitly request
> sepostgresql or row-level DAC.
Yes, if there is concern about row-level security turning off
optimizations, some flag would have to be checked so the optimization
would be possible for sites not using row-level security; ideally there
would be a table-level flag, and I think the current patch implements it
that way.
--
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 | Tom Lane | 2009-01-28 22:45:31 | Re: 8.4 release planning |
| Previous Message | Bruce Momjian | 2009-01-28 22:40:34 | Re: 8.4 release planning |