On 9 January 2013 21:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 9 January 2013 21:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This sounds like rather a lot of work to create a behavior that doesn't
>>> solve the originally-complained-of usability problem. All it does is
>>> make things even more complicated, and add an extra step for the DBA
>>> who's just trying to set temp_tablespaces to something useful.
>> There is already an extra step to GRANT the CREATE privilege, so how
>> does this change things?
> The point is that it didn't occur to Stephen that putting
> temp_tablespaces = 'foo, bar' into postgresql.conf should require
> doing GRANT CREATE TO PUBLIC on those tablespaces in order to be
> effective. Changing the situation so that instead he needs to do
> GRANT TEMP TO PUBLIC does not make it one whit more usable.
> All that that will really accomplish is to break grant methods that are
> working in (other people's) existing installations; ie if someone has
> code that does know about the GRANT CREATE requirement, he will not
> thank us if he suddenly has to spell it GRANT TEMP in the next release.
> If we were designing this from scratch I'd agree that a separate TEMP
> privilege would be a good thing. But bolting one on now is likely
> to create more problems than it fixes. Particularly since it doesn't
> actually fix any of the concrete problems enumerated in this thread.
> I continue to think that getting rid of the privilege check would be
> a more useful answer than changing which privilege is tested.
I wasn't suggesting that we test for TEMP instead of CREATE; what I
meant was we would test for CREATE *OR* TEMP to give more options for
management. Since CREATE is a powerful privilege, secure systems would
not wish to grant that to everyone, which is what I think caused the
issue, coupled with the inability to know whether temp_tablespaces is
set to something you have privileges on.
Your suggestion to make TEMP the default would be a useful way to
handle this, but its still the opposite of how things work now.
Granting CREATE by default on tablespaces is not a great plan.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2013-01-09 22:06:49|
|Subject: Re: Reducing size of WAL record headers|
|Previous:||From: Andrew Dunstan||Date: 2013-01-09 21:49:30|
|Subject: Re: PL/perl should fail on configure, not make|