Thread: tsvector_update_trigger() is utterly insecure

We can't put tsvector_update_trigger() into core in anything like its
current form.  As is, it will take an unqualified function name, look
it up, and call it.  The prospects for subversion by search path
manipulation are obvious, and even if you aren't concerned about
malicious attacks, the effects of the trigger are context-dependent
(and maybe time-varying; it doesn't insist on the function being
immutable) in exactly the same way that we've been saying we can't
accept for the tsearch configuration.

I think we should redefine the trigger as taking trigger arguments that
are first a config name, then a list of one or more field names, and
nothing else.

People who want extra processing done on their fields before forming the
tsvector can write custom triggers to do it ...
        regards, tom lane

Tom Lane wrote:
> We can't put tsvector_update_trigger() into core in anything like its
> current form.  As is, it will take an unqualified function name, look
> it up, and call it.  The prospects for subversion by search path
> manipulation are obvious, and even if you aren't concerned about
> malicious attacks, the effects of the trigger are context-dependent
> (and maybe time-varying; it doesn't insist on the function being
> immutable) in exactly the same way that we've been saying we can't
> accept for the tsearch configuration.
> 
> I think we should redefine the trigger as taking trigger arguments that
> are first a config name, then a list of one or more field names, and
> nothing else.
> 
> People who want extra processing done on their fields before forming the
> tsvector can write custom triggers to do it ...

Agreed.  A stated in email I didn't like the filter API on style
grounds.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +