Re: Review of GetUserId() Usage

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review of GetUserId() Usage
Date: 2014-12-05 15:02:56
Message-ID: 20141205150256.GM25679@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> Is the 'Only allow superusers to signal superuser-owned backends' check
> actually safe that way? I personally try to never use a superuser role
> as the login user, but grant my account a superuser role that doesn't
> inherit. But IIRC PGPROC->roleId won't change, even if a user does SET
> ROLE.

You're correct- but it's exactly the same as it is today. If you grant
another user your role and then they 'SET ROLE' to you, they can cancel
any of your queries or terminate your backends, regardless of if those
roles have done some other 'SET ROLE'. This change only removes the
need for those users to 'SET ROLE' to your user first.

The backend isn't considered 'superuser-owned' unless it's the login
role that's a superuser. It might be interesting to change that to mean
'when a SET ROLE to superuser has been done', but what about security
definer functions or other transient escalation to superuser? Would
those calls have to muck with PGPROC->roleId?

If we want to go there, it should definitely be a different patch.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-12-05 15:05:12 Re: XLOG_PARAMETER_CHANGE (WAL record) missing two params in its desc routine
Previous Message Andres Freund 2014-12-05 14:45:22 Re: Review of GetUserId() Usage