[ postfixadmin-Bugs-2951471 ] Table prefix issue fixed

[SourceForge.net <no...@so...>]

Bugs item #2951471, was opened at 2010-02-14 05:54
Message generated for change (Comment added) made by christian_boltz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2951471&group_id=191583

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database
Group: v 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Uwe Walter (uwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Table prefix issue fixed

Initial Comment:
Found that the table_by_key() function on the second call only returns the table_prefix.

Patch attached

----------------------------------------------------------------------

>Comment By: Christian Boltz (christian_boltz)
Date: 2010-02-21 17:06

Message:
Well, I'm not that strict on paperworks ;-)

You found an interesting[tm] bug, but I'll use a different fix.

The problem is IMHO not that table_by_key is called twice for a table (I
would hopefully notice that because I use a table_prefix in my test
environment since some time). I don't like the "called twice" check because
it might cause funny problems - think of a prefix "mail", which will also
match the "mailbox" table and leave it without prefix.

The real bug (in trunk) is: table_by_key returned only the
$CONF[database_prefix] if a table was unknown in $CONF[database_tables] and
$CONF[database_prefix] was not empty.
-> fixed in SVN r804 (for trunk)

2.3 has a slightly different bug - it does not prepend the database_prefix
if a table is not listed in database_tables. I'll probably not fix this in
the 2.3 branch - even if it gives wrong results, it is consistent. Fixing
it would break compatibility ;-)

Another thing you mention in your patch's README:
> Consider a real DAU noob, thinking he was just a bit smarter than all
the other
> ones, setting a table_prefix containing cryptic special chars. Under
MySQL
> this is not a problem, because you can simply `back tick`, respectively
> name-quote them, but not so under PostgreSQL. Here I would consider a
plpgsql
> function, building the table name.

My favorite quote on this is:
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.

Basically your comment is correct - but with a crazy prefix, setup.php
will fail already and the admin will hopefully choose another one that is
more sane. Yes, we could add a function to handle such crazy prefixes or
table names, but
- it adds lots of complexity with no real value for 99.9% of the users
- it will never catch _all_ special chars, so it can't be called a real
fix (which is the main reason why I'm against it)
The only thing I would accept is checking table names and the prefix
against a character whitelist (maybe [a-zA-Z0-9_-] - which other chars
should be allowed?) and die() if anything else is included. 

> Greetings from Mainz!

Greetings from Insheim (near Landau) :-)

----------------------------------------------------------------------

Comment By: Uwe Walter (uwalter)
Date: 2010-02-14 06:12

Message:
I'm so sorry, just saw that here's a patch section also. Would you please
be so kind and move this ticket there.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2951471&group_id=191583