On Mon, Jan 25, 2021 at 3:17 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> > Yes, if required backends can establish the connection again. But my
> > worry is this - a non-super user disconnecting all or a given
> > connection created by a super user?
>
> Yes, I was also worried about that. But I found that there are other similar cases, for example,
>
> - a cursor that superuser declared can be closed by non-superuser (set by SET ROLE or SET SESSION AUTHORIZATION) in
thesame session.
> - a prepared statement that superuser created can be deallocated by non-superuser in the same session.
>
> This makes me think that it's OK even for non-superuser to disconnect the connections established by superuser in the
samesession. For now I've not found any real security issue by doing that yet. Thought? Am I missing something?
Oh, and added to that list is dblink_disconnect(). I don't know
whether there's any security risk if we allow non-superusers to
discard the super users connections. In this case, the super users
will just have to re make the connection.
> > For now I'm thinking that it might better to add the restriction like pg_terminate_backend() at first and relax
thatlater if possible. But I'd like hear more opinions about this.
>
> I agree. If required we can lift it later, once we get the users using
> these functions? Maybe we can have a comment near superchecks in
> disconnect_cached_connections saying, we can lift this in future?
Maybe we can do the opposite of the above that is not doing any
superuser checks in disconnect functions for now, and later if some
users complain we can add it? We can leave a comment there that "As of
now we don't see any security risks if a non-super user disconnects
the connections made by super users. If required, non-supers can be
disallowed to disconnct the connections" ?
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com