Обсуждение: 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. +