Re: tsearch filenames unlikes special symbols and numbers

On 9/3/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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.

I don't know what you're discussing well enough to know if this is
relevant, but what you just said is not always true. If there is any
way to pass arbitrary binary data into your function call, then
someone can pass in a string with nul in it. When that hits the OS
API, your appended .dict won't be seen as part of the filename.

(This is a common security oversight when calling C APIs from
higher-level languages such as Perl. See
http://artofhacking.com/files/phrack/phrack55/P55-07.TXT for more.)

[...]

Cheers,
Ben