Re: Restrict permissions on schema to hide pl/pgsql code - Mailing list pgsql-admin

From richard coleman
Subject Re: Restrict permissions on schema to hide pl/pgsql code
Date
Msg-id CAGA3vBuMYQfN7oGb9uH4mU-jb-N10=oh1S6VTJuMOb_HPz3mFQ@mail.gmail.com
Whole thread Raw
In response to Re: Restrict permissions on schema to hide pl/pgsql code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Restrict permissions on schema to hide pl/pgsql code  (Thomas Kellerer <spam_eater@gmx.net>)
List pgsql-admin
I guess that just means postgresql probably shouldn't be used in a multi-tenancy situation if you need; 
  • complete isolation between tenants
  • you still want to give tenants direct and otherwise unfettered access to the database
just a thought, 

rik.

On Wed, Jul 24, 2019 at 1:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> You can consider this email to have accomplished both.  Lacking someone
> saying they they are working on it and pointing you to a patch you can
> safely operate under the assumption that this behavior isn’t going to
> change.

It isn't.  We've considered complaints like this before and determined
that we're not going to do anything about it.  For better or worse, the
PG catalogs are readable by any authorized user, with only narrow
exceptions (like password columns).

A sufficiently determined person could perhaps do something like creating
their own PL that stores encrypted function source text in pg_proc, and
just hands it off to an existing PL after decryption.  I'm not exactly
sure where you'd keep the decryption key though.

                        regards, tom lane


pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: Restrict permissions on schema to hide pl/pgsql code
Next
From: Thomas Kellerer
Date:
Subject: Re: Restrict permissions on schema to hide pl/pgsql code