Re: db_user_namespace a "temporary measure"
От | Magnus Hagander |
---|---|
Тема | Re: db_user_namespace a "temporary measure" |
Дата | |
Msg-id | CABUevEzqNLHn_BD6vOQ6KDbZSah0GBtyYmOPuSWfXkhttR9mbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: db_user_namespace a "temporary measure" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: db_user_namespace a "temporary measure"
Re: db_user_namespace a "temporary measure" |
Список | pgsql-hackers |
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:A local user with the superuser privilege would not be able to log into
>> Yeah, what we really need is encapsulated per-DB users and local
>> superusers. I think every agrees that this is the goal, but nobody
>> wants to put in the work to implement a generalized solution.
> Encapsulated would probably be the doable part. But local superuser? Given
> that a superuser can load and run binaries, how would you propose you
> restrict that superuser from doing anything they want? And if you don't
> need that functionality, then hows it really different from being the
> database owner?
another database, because superuser doesn't give you any extra privilege
until you've logged in.
Yeah, as superuser you could still break things as much as you pleased,
but not through SQL.
You could COPY over the hba file or sometihng like that :) Or just pg_read_binary_file() on the files in another database, which is accessible through SQL as well.
I share your doubts as to how useful such a concept actually is, but
it'd work if we had real local users.
It can also do interesting things like ALTER SYSTEM, replication, backups, etc. All of which could be used to escalate privileges beyond the local database.
So you'd have to somehow restrict those, at which point what's the point of the property in the first place?
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: