Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> it considers the following to be an absolute path:
> * Anything that starts with /
> * Anything that starst with \
These aren't truly absolute, because the directory you find will be
based on your current work directory's drive letter; however, if the
point is to then check whether it falls under the current work
directory, even when an absolute path is specified, it works.
> * Anything alphanumerical, followed by a colon, followed by either
> / or \
I assume we reject anything where what precedes the colon doesn't
match the current drive's designation?
> However, it misses the case with for example E:foo, which is a
> perfectly valid path on windows. Which isn't absolute *or*
> relative - it's relative to the current directory on the E: drive.
> This function is used in the genfile.c functions to read and list
> files by admin tools like pgadmin - to make sure we can only open
> files that are in our own data directory - by making sure they're
> either relative, or they're absolute but rooted in our own data
> directory. (It rejects anything with ".." in it already).
Well, if that's a good idea, then you would need to reject anything
specifying a drive which doesn't match the drive of the data
directory. Barring the user from accessing directories on the
current drive which aren't under the data directory on that drive,
but allowing them to access any other drive they want, is just
silly.
It does raise the question of why we need to check this at all,
rather than counting on OS security to limit access to things which
shouldn't be seen.
-Kevin