From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: [PATCHES] createdb/dropdb fixes |
Date: | 1999-12-14 16:45:49 |
Message-ID: | 15662.945189949@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> Meanwhile, database names with single quotes in names don't work very well
>> at all, and because of shell quoting rules this can't be fixed, so I put
>> in error messages to that end.
> That seems to be a bit heavy handed; why bother disallowing things in
> the backend because some (small number of) shell-based tools have
> trouble as clients? I'd prefer filtering that at the client end, and
> allowing capable clients to do whatever they please.
No, you're missing the point: the backend itself uses shell escapes
for some whole-database functions. IIRC, database creation is done with
something like
system("cp -r base/template1 base/newdb");
So shell metacharacters in database names are Bad News. We need to
put in a filter that will prevent appearances of / | ` etc in DB names.
I assume that's what Peter was doing.
I think we may have some bugs with metacharacters in table names (which
become filenames) as well, but haven't really pushed on it.
> thinking about recoding ACLs as a two-field type to enforce an
> unambigous interpretation of the two fields. Interested??
Seems like a good idea.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1999-12-14 17:27:24 | Transactions ... |
Previous Message | Bruce Momjian | 1999-12-14 16:27:47 | Re: [HACKERS] 6.6 release |