A couple months ago I wrote:
> Lastly, I'm unhappy that the patch still keeps a lot of configuration
> information, such as stop word lists, in the filesystem rather than the
> database. It seems to me that the single easiest and most useful part
> of a configuration to change is the stop word list; but this setup
> guarantees that no one but a DBA can do that, and what's more that
> pg_dump won't record your changes. What's the point of having any
> non-superuser configuration capability at all, if stop words aren't part
> of what you can change?
It appears that nothing has been done about this objection in the
current patch. It is too late to redesign stop word handling for 8.3,
but right now I have a more limited complaint: the patch allows
unprivileged users to specify stopword files with absolute paths.
This is a serious security breach, since it allows unprivileged users
to read arbitrary files with the permissions of the postgres user.
Now they maybe would have some difficulty determining the exact contents
of such a file, but it would certainly be easy to test for the existence
of particular words in it.
What I think we should do about this is the same as we do for timezone
abbreviation sets: the user-given stopword specification is just a name,
which we insist can't contain dots or directory separators, and then
we look up "$SHAREDIR/dict_data/NAME.stop" (or other suffixes for the
other kinds of configuration files). This closes the security hole
and also gives us a chance at an upward-compatible redesign later ---
for instance, in a future release the name might refer to an entry in
some other system catalog, rather than a file.
BTW, I'm inclined to rename the installation directory to
$SHAREDIR/tsearch_data/ ... any objections to that?
regards, tom lane