Re: pg_tablespace_size()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_tablespace_size()
Дата
Msg-id 28736.1192206253@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_tablespace_size()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_tablespace_size()  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
I wrote:
> [ squint... ]  There is something wrong here, because a superuser should
> certainly pass the aclcheck test.  I don't know where the bug is but
> this is not the correct fix.

OK, after looking, the issue is this wart in pg_tablespace_aclmask():
   /*    * Only shared relations can be stored in global space; don't let even    * superusers override this    */   if
(spc_oid== GLOBALTABLESPACE_OID && !IsBootstrapProcessingMode())       return 0;
 
   /* Otherwise, superusers bypass all permission checking. */

There are a number of ways that we could deal with this:

* Just remove the above-quoted lines.  Superusers should be allowed to
shoot themselves in the foot.  (I'm not actually sure that there would
be any bad consequences from putting an ordinary table into pg_global
anyway.  I think I wrote the above code in fear that some parts of the
system would equate reltablespace = pg_global with relisshared, but
AFAICS that's not the case now.)

* Remove the above lines and instead put a defense into heap_create.
This might be better design anyway since a more specific error could
be reported.

* Leave aclchk.c as-is and apply Magnus' patch to allow superusers
to bypass the check in pg_tablespace_size.

* Decide that we should allow anyone to do pg_tablespace_size('pg_global')
and put in a special wart for that in dbsize.c.  This wasn't part of
the original agreement but maybe there's a case to be made for it.

Thoughts?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: pg_tablespace_size()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Locales and Encodings