Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> I'm not convinced that . is issue-free. On most if not all versions of Unix,
>> you are allowed to open a directory as a file and read the filenames it
>> contains. While I don't say it'd be easy to manage that through
>> tsearch, there's at least a potential for discovering the filenames
>> present in . and .. --- how much do we care about that?
> Actually I don't think that's true any more, most file systems on most Unixen
> do not allow it. However it appears it's still the case for Solaris so it's
> still a good point.
Actually, now that I've woken up a bit more, it is not a problem as
long as the tsearch code always appends some kind of file extension
to what the user gives, such as ".dict". It'll be impossible to name
"." or ".." with that addition.
Also, Magnus says that Windows throws an error for ":" in the filename,
which means we needn't.
So the bottom line seems to be that rejecting directory separators
is sufficient to prevent any unwanted file accesses.
It might still be a good idea to restrict the names to be SQL
identifiers (ie, alphanumerics and underscores) for future-proofing,
but it wasn't clear whether anyone but me thought that was a good
argument. I'm willing to make it just be no-dir-separators.
regards, tom lane