On 1999-12-14, Tom Lane mentioned:
> 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 "..".
My rm refuses to remove '..' and '.'.
> 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.
The slash problem will disappear (I hope) when I fix that alternate
location issue.
> 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
Spaces why not? I use spaces all the time in filenames. But perhaps we
should make a definite list of things we won't allow, such as dots (.),
slashes (/), tildes (~), etc., and everything below ASCII 32. But limiting
it to a finite list of characters would really be a blow to people using
other character sets.
> > Of course this particular case might as well use unlink(),
>
> Not unless your system's unlink is much different from mine's...
Is it just me or is your system intentionally designed to be different
from anybody elses? :) Last time I checked rm does call unlink. Relying on
sh-utils sort of commands has its own set of problems. For example in the
6.5 source, run the postmaster on a terminal, revoke all permissions on a
database directory (chmod a-rwx testdb) and try to drop it. My rm will
prompt on the postmaster terminal for verification while the whole thing
hangs ...
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden