Re: "set role" semantics - Mailing list pgsql-general

On 11/9/22 12:31, Bryn Llewellyn wrote:

> Thanks. If nobody thinks that ending up as I showed is possible brings any kind of risk, then I’m happy to accept
that.More generally, I’m a huge fan of the principle of least privilege, and (as far as it concerns what I asked about
inthis thread), its following aspect:
 
> 
> If you consider these two alternatives:
> 
> Alt. #1: Some ability that you do not need (and therefor don’t want) is simply not available.
> 
> Alt. #2: That unwanted ability is available, but reasoning shows that it’s harmless.
> 
> then Alt. #1 is preferable.
> 
> But I do see that I can’t get Alt #1 here.
> 
> In my actual use case, every role apart from "postgres", and its non-superuser deputy with "create role" and
"createdb",will be confined at "connect time" to exactly one database. And those of these that will be able to "set
role"will be able to do this only to other roles that are also confined (at "connect" time) to the same database.
Moreover,I cannot worry about what sessions that authorize as "postgres" or its deputy can do because the former is
unstoppable"and the latter is dangerously powerful in the wrong human hands. There's always a need for trusted humans
who,if they betray that trust, can do untold harm. In this case, they must understand the design of the "multitenancy
byconvention" scheme and must be committed to honoring it. So, sure enough, reasoning tells me that my plan is sound.
 
> 
> Nevertheless, it does seem to be unfortunate to take the mechanics of "connect" as salient rather than the resulting
stateof the session that either "connect" or "set role" can bring about. There could be (in a future PG version) a
privilegethat governed "set role" in the present scenario. But I'm sure that there never will be.
 

Connecting to database and the role that is in play inside a session are 
two different things. Making them the same would make things like from here:

https://www.postgresql.org/docs/current/sql-createfunction.html

[EXTERNAL] SECURITY INVOKER
[EXTERNAL] SECURITY DEFINER

     SECURITY INVOKER indicates that the function is to be executed with 
the privileges of the user that calls it. That is the default. SECURITY 
DEFINER specifies that the function is to be executed with the 
privileges of the user that owns it.

     The key word EXTERNAL is allowed for SQL conformance, but it is 
optional since, unlike in SQL, this feature applies to all functions not 
only external ones.

go sideways.



> 
> <aside>
> You mentioned access to the catalog tables. This, too, belongs to the discussion of the principle of least privilege.
Thisaccess is not hard wired. Rather, it's just a manifestation of the default regime. I've prototyped a regime where
theprivileges that you need to access these tables (and other things too) are revoked from public and (for convenience)
aregranted to a single dedicated role. This means that it's easy to make it such that the role(s) that clients use to
connectcan't query the catalog—or, if you prefer, can access exactly and only those catalog items that they need to.
I'mpleased with how it worked out. And I'll pursue this regime further.
 
> </aside>

Have you actually done that and tried to run SQL statements?

They are called system catalogs because they are used by the system to 
get the information necessary to do things. Throwing restrictions on 
their access would be akin to pouring sand in a gearbox, lots of strange 
behavior and then nothing.


-- 
Adrian Klaver
adrian.klaver@aklaver.com