Re: db_user_namespace a "temporary measure"

On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> >> 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?
>
> A local user with the superuser privilege would not be able to log into
> 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/