On 02/26/2017 02:54 PM, Tom Lane wrote: > * I'm not terribly comfortable about what the permissions levels of the > GUCs ought to be. The call permissions check means that you can't use > either GUC to call a function you couldn't have called anyway. However > there's a separate risk of trojan-horse execution, analogous to what a > blackhat can get by controlling the search_path GUC setting used by a > SECURITY DEFINER function: the function might intend to invoke some pltcl > function, but you can get it to invoke some other pltcl function in > addition to that. I think this means we had better make pltclu.start_proc > be SUSET, but from a convenience standpoint it'd be nice if > pltcl.start_proc were just USERSET. An argument in favor of that is that > we don't restrict search_path which is just as dangerous; but on the other > hand, existing code should be expected to know that it needs to beware of > search_path, while it wouldn't know that start_proc needs to be locked > down. Maybe we'd better make them both SUSET. >
plperl's on_plperl_init and on_plperlu_init settings are both SUSET. In practice with PLv8 this is usually set in the config file in my experience. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
