From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | sszabo(at)bigpanda(dot)com |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Database names with spaces |
Date: | 2000-05-31 21:07:46 |
Message-ID: | 200005312107.RAA29977@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Can someone comment on this?
>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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
>
> ************
>
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-31 21:17:55 | Re: [HACKERS] Failures with arrays |
Previous Message | Bruce Momjian | 2000-05-31 20:46:01 | more cvs problems |