Bug 725123

Summary: certain queries generated by phpmyadmin are rejected my the server with "unclosed quote"
Product: [Fedora] Fedora EPEL Reporter: manuel wolfshant <wolfy>
Component: phpMyAdminAssignee: Robert Scheck <redhat-bugzilla>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el5CC: redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: phpMyAdmin-2.11.11.3-2.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-16 20:57:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description manuel wolfshant 2011-07-22 23:23:03 UTC
Description of problem:
Certain queries generated by phpMyAdmin ( while trying to edit an existing row ) are not accepted by the database server. Instead of the normal result there is an error, similar to http://forums.devshed.com/mysql-help-4/mysql-phpmyadmin-problem-139377.html and http://drupal.org/node/72405

Version-Release number of selected component (if applicable):
phpMyAdmin-2.11.11.3-1.el5.noarch.rpm 

How reproducible:
  always

Steps to Reproduce:
I cannot provide access to my internal setup but see the links above or http://www.google.com/search?q=phpmyadmin+"unclosed+quote" .
  
Actual results:

ERROR: Unclosed quote @ 272  <==== this number varies with the query
STR: '


Basically the query is rejected at the first ' character preceding the content of the field.


Expected results:

The query should be executed by the server.

Additional info:
phpmyadmin was installed on a centos 5 box ( running php-5.3.6 from IUS ). The problem appears both with the db server running mysql-server 4.1.22-2.el4_8.4 package from Centos 4.9 and with mysql50-5.0.92-1.ius.el4.

I've rebuilt the current phpmyadmin.src.rpm from F15 ( 3.4.3 ) and the problem is gone. The following warning is displayed: "The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated. To find out why click here.", but everything seems to work OK so far.

Comment 1 Robert Scheck 2011-07-26 16:57:26 UTC
I've now set up a test environment which is as follows:

 vm1: CentOS 4 + mysql-server-4.1.22-2.el4_8.4
 vm2: CentOS 5 + php53-5.3.3-1.el5_6.1 (official!)
               + phpMyAdmin-2.11.11.3-1.el5 (rpm --nodeps)

Via phpMyAdmin, I created a new database and a table with 1 varchar(25) field.
Afterwards I inserted one row using phpMyAdmin with a "'" (without the "") and
same with "`" (without the "" again).

It just works. May you provide me more details? Do you have any non-default PHP 
settings?

Comment 2 manuel wolfshant 2011-07-26 17:19:16 UTC
First of all, thank you for looking into this.


I am extremely sorry but I could not afford to keep the system in that state, I had to upgrade (before even filing the bugz). Even today I have upgraded to the version that you have pushed yesterday to EPEL-6 ( recompiled for EL-5).


The difference that I can spot between our setup and your tests is that we are using the php53u stack on the centos 5 machine. The version of mysql-server did not seem to matter, I had exactly the same problem both with the official mysql-server-4.1.22-2.el4_8.4, with mysql50-server.i386 5.0.92-1.ius.el4 and also with mysql-5.0.42-1.el4.centos.i386.rpm from centos-testing.

If this helps, the issue appeared always when trying to edit any of the varchar rows from the following table :

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;


CREATE TABLE IF NOT EXISTS `Personal` (
  `nume` varchar(30) default NULL,
  `prenume` varchar(30) default NULL,
  `nickname` varchar(30) default NULL,
  `extension` varchar(10) default '0',
  `wiki_url` varchar(255) character set utf8 default NULL COMMENT 'the wiki url of the guys',
  `ReadRight` tinyint(1) default NULL,
  `Personal_ID` int(5) NOT NULL auto_increment,
  `staff` int(5) default NULL,
  `leader` int(5) default NULL,
  `available` smallint(6) default NULL,
  `date` varchar(30) NOT NULL default '',
  KEY `Personal_ID` (`Personal_ID`),
  FULLTEXT KEY `date` (`date`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 COMMENT='lista cu angajati' AUTO_INCREMENT=408 ;

Comment 3 Robert Scheck 2011-07-26 18:12:46 UTC
"magic_quotes_gpc = On" triggers the bug in libraries/common.inc.php:236

This issue has been already fixed in 3.x, it only affects 2.x - and only,
if somebody uses this deprecated functionality.

Comment 4 Fedora Update System 2011-07-26 20:27:25 UTC
phpMyAdmin-2.11.11.3-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/phpMyAdmin-2.11.11.3-2.el5

Comment 5 Fedora Update System 2011-07-26 20:27:45 UTC
phpMyAdmin-2.11.11.3-2.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/phpMyAdmin-2.11.11.3-2.el4

Comment 6 Fedora Update System 2011-07-30 10:34:33 UTC
Package phpMyAdmin-2.11.11.3-2.el4:
* should fix your issue,
* was pushed to the Fedora EPEL 4 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing phpMyAdmin-2.11.11.3-2.el4'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/phpMyAdmin-2.11.11.3-2.el4
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2011-08-16 20:57:47 UTC
phpMyAdmin-2.11.11.3-2.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2011-08-16 20:58:36 UTC
phpMyAdmin-2.11.11.3-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.