Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> > Looks like a bug. Added to TODO list.
>>
>> >> I see a todo item
>> >> * Views with spaces in view name fail when referenced
>> >>
>> >> I have another one for you:
>> >> * Databases with spaces in name fail to be created and destroyed despite
>> >> responses to the contrary.
>
>> IIRC, createdb and destroydb use "cp -r" and "rm -r" respectively.
>> Lack of careful quoting in the system calls is probably what's
>> causing the problem here.
>>
>> However, I wonder if it wouldn't be a better idea to forbid funny
>> characters in things that will become Unix filenames. In particular,
>> something like CREATE DATABASE "../../../something" could have real
>> bad consequences...
>
>I just tried it:
>
> test=> create database "../../pg_hba.conf"
> test-> \g
> ERROR: Unable to locate path '../../pg_hba.conf'
> This may be due to a missing environment variable in the server
>
>Seems we are safe.
(This is my first time going through the code, so I could be getting alot of
things wrong, but here's what I see...)
The function createdb in backend/commands/dbcommands.c (I assume this is right
because it seems to do the correct thing and actually define the above error
message) tries to get the path to the database using ExpandDatabasePath on
either dbpath/dbname or just dbname depending on whether dbpath is null (or
same as dbname).
ExpandDatabasePath in backend/utils/misc/database.c seems to assume that anything
that has the separator character ('/' i would assume) is of the form
environmentvariable/<rest> which seems to be rewritten into
<value of environment variable>/base/<rest>
So with your example it fails because it can't find the environment variable
'..' (although if you had one, it might actually attempt to put it wherever
that would point)
It then makes a command and systems:
COPY_CMD DataDir/base/template1/ <return from ExpandDatabasePath>
When i tried to do a:create database "`a.sh`" on a little shell script in the PATH, it decided
to copy the stuff from template1 into my data/base directory. The shell
script touches a file in tmp, which was touched.
It seems like the current implementation would let someone run a command in
backticks that is in the postgres user's path as long as there are no
directory name separators in the command.
Stephan Szabo
