Re: Privilege boundary between sysadmin and database superuser [Was: Re: pg_amcheck option to install extension]

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Privilege boundary between sysadmin and database superuser [Was: Re: pg_amcheck option to install extension]
Date: 2021-04-21 00:30:56
Message-ID: 175D387B-7FAD-4183-9EF2-07AAEC5ED103@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Apr 20, 2021, at 3:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>>> On Apr 20, 2021, at 5:54 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
>>> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>>>> I think you are conflating the concept of an operating system adminstrator with the concept of the database superuser/owner.
>
>>> You should conflate those things, because there's no meaningful
>>> privilege boundary between them:
>
>> I understand why you say so, but I think the situation is more nuanced than that.
>
> Maybe I too am confused, but I understand "operating system administrator"
> to mean "somebody who has root, or some elevated OS privilege level, on
> the box running Postgres". That is 100% distinct from the operating
> system user that runs Postgres, which should generally be a bog-standard
> OS user. (In fact, we try to prevent you from running Postgres as root.)
>
> What there is not a meaningful privilege boundary between is that standard
> OS user and a within-the-database superuser. Since we allow superusers to
> trigger file reads and writes, and indeed execute programs, from within
> the DB, a superuser can surely reach anything the OS user can do.

Right. This is the part that Alice might want to restrict, and we don't have an easy way for her to do so.

> The rest of your analysis seems a bit off-point to me, which is what
> makes me think that one of us is confused. If Alice is storing her
> data in a Postgres database, she had better trust both the Postgres
> superuser and the box's administrators ... otherwise, she should go
> get her own box and her own Postgres installation.

It is the other way around. Alice is the operating system administrator who doesn't trust Bob. She wants Bob to be able to do any database thing he wants within the PostgreSQL environment, but doesn't want that to leak out as an ability to run arbitrary stuff on the system, not even if it's just stuff running as bog-standard user "postgres". In my view, Alice can accomplish this goal using a very tightly designed container, but it is far from easy to do and to get right.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-21 00:31:34 Re: Table refer leak in logical replication
Previous Message Andres Freund 2021-04-21 00:20:56 Re: terminate called after throwing an instance of 'std::bad_alloc'