On Friday, February 23, 2024 5:07 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > On Fri, Feb 23, 2024 at 02:15:11PM +0530, shveta malik wrote: > > On Fri, Feb 23, 2024 at 1:28 PM Bertrand Drouvot > > <bertranddrouvot...@gmail.com> wrote: > > > > > > Hi, > > > > > > Because one could create say the "=" OPERATOR in their own schema, > > > attach a function to it doing undesired stuff and change the > > > search_path for the database the sync slot worker connects to. > > > > > > Then this new "=" operator would be used (instead of the > > > pg_catalog.= one), triggering the "undesired" function as superuser. > > > > Thanks for the details. I understand it now. We do not use '=' in our > > main slots-fetch query but we do use '=' in remote-validation query. > > See validate_remote_info(). > > Oh, right, I missed it during the review. > > > Do you think instead of doing the above, we can override search-path > > with empty string in the slot-sync case. > > SImilar to logical apply worker and autovacuum worker case (see > > InitializeLogRepWorker(), AutoVacWorkerMain()). > > Yeah, we should definitively ensure that any operators being used in the query > is coming from the pg_catalog schema (could be by setting the search path or > using the up-thread proposal). > > Setting the search path would prevent any risks in case the query is changed > later on, so I'd vote for changing the search path in validate_remote_info() > and > in synchronize_slots() to be on the safe side.
I think to set secure search path for remote connection, the standard approach could be to extend the code in libpqrcv_connect[1], so that we don't need to schema qualify all the operators in the queries. And for local connection, I agree it's also needed to add a SetConfigOption("search_path", "" call in the slotsync worker. [1] libpqrcv_connect ... if (logical) ... res = libpqrcv_PQexec(conn->streamConn, ALWAYS_SECURE_SEARCH_PATH_SQL); Best Regards, Hou zj