Peter Eisentraut <peter_e@gmx.net> writes:
> It's really about statements like this:
> snprintf(buf, sizeof(buf), "rm -rf '%s'", path);
> There is no way around disallowing single-quotes unless you double quote
> the argument and be very careful with the escaping.
Yes. In fact, I'd argue for filtering the names more heavily than that;
just to take a for-example, Bad Things would ensue if we accepted a
database name of "..".
It is easy to devise cases in which accepting leading "." or embedded "/"
leads to disaster; if you think those are OK, allow me to destroy your
installation for you ;-). I haven't yet thought of a way to cause
trouble with a back-quote in a DB name (given that single quotes are
disallowed) ... but I bet some enterprising hacker can find one.
Beyond the bare minimum security issues, I also think we should take
pity on the poor dbadmin who may have to be looking at these
subdirectories or filenames. Is it really a good idea to allow carriage
returns or other control characters in file/directory names? Is it
even a good idea to allow spaces? I don't think so. If we were not
using these names for Unix file/dir names then we could allow anything
we felt like --- but since we are using them that way, I think that the
safest path is to only allow things that are going to look like ordinary
file names when used in Unix shell commands. Otherwise there's still a
big chance of trouble if the dbadmin gets a little bit careless.
> Of course this particular case might as well use unlink(),
Not unless your system's unlink is much different from mine's...
regards, tom lane
