Re: allowing privileges on untrusted languages

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: allowing privileges on untrusted languages
Дата
Msg-id 20903.1358697198@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: allowing privileges on untrusted languages  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: allowing privileges on untrusted languages  (Robert Haas <robertmhaas@gmail.com>)
Re: allowing privileges on untrusted languages  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: allowing privileges on untrusted languages  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Yeah.  We'd need to think a little bit about how to make this work,
> since I think that adding a gajillion booleans to pg_authid will not
> make anyone very happy.  But I like the idea.  GRANT
> kill_sessions_of_other_users TO bob?  GRANT install_untrusted_pls TO
> any_database_owner?  GRANT install_an_extension_called(hstore) TO
> any_database_owner?  I know there are other ways of doing all of these
> things, so don't take the specific proposals too seriously, but we
> clearly have a need to parcel out controlled bits of the superuser
> mojo to individual users in a nice, clean, convenient way.  Getting
> agreement on the details is likely to be difficult, but it seems like
> a good concept from 10,000 feet.

The traditional answer to that, which not only can be done already in
all existing releases but is infinitely more flexible than any
hard-wired scheme we could implement, is that you create superuser-owned
security-definer functions that can execute any specific operation you
want to allow, and then GRANT EXECUTE on those functions to just the
people who should have it.

I'm really entirely un-thrilled with a proposal to clutter the privilege
system like this.  Admittedly, it might be a hair more secure than
user-written plpgsql functions, which could perhaps be subverted if the
author is careless.  But there are a hundred other places where we could
more usefully spend our implementation and future-maintenance efforts
than here.
        regards, tom lane



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCH] Fix off-by-one in PQprintTuples()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #7809: Running pg_dump on slave w/ streaming replication fails if there are unlogged tables