Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
От | Bharath Rupireddy |
---|---|
Тема | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |
Дата | |
Msg-id | CALj2ACUJtiCjnqcfQDT5q0C7O=PanN_rtgjkuh7mMh4uuzXf7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: