Hi Marc & list,
-----Original Message----- From: Marc Delisle
We got a report from a user, his ISP has disabled ini_get() and mysql_list_dbs() for security reasons.
Problem is, in this case, function_exists('ini_get') is true even if ini_get() is disabled.
I just read in php's ChangeLog http://www.php.net/ChangeLog-4.php that this issue has been fixed in php 4.3.0. In recent php versions, function_exists should return FALSE for disabled functions.
Regards,
Alexander M. Turek alex@bugfixes.info
+-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
Alexander,
you are right and I just tested it: PHP 4.3.0 returns FALSE when ini_get is disabled.
So we could put the @ in front of the 2 ini_get calls, as suggested in the bug report, but this means they won't be able to upload. I smell a new faq entry about upgrading their PHP:)
Do you want me to do the job?
Marc
Alexander M. Turek wrote:
Hi Marc & list,
-----Original Message----- From: Marc Delisle
We got a report from a user, his ISP has disabled ini_get() and mysql_list_dbs() for security reasons.
Problem is, in this case, function_exists('ini_get') is true even if ini_get() is disabled.
I just read in php's ChangeLog http://www.php.net/ChangeLog-4.php that this issue has been fixed in php 4.3.0. In recent php versions, function_exists should return FALSE for disabled functions.
Regards,
Alexander M. Turek alex@bugfixes.info
+-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi!
So we could put the @ in front of the 2 ini_get calls, as suggested in the bug report, but this means they won't be able to upload. I smell a new faq entry about upgrading their PHP:)
Can't we put an override file_upload directive in the configuration? I don't see why users shouldn't be able to use a function only because a hoster forbids the function to see whether a function is available. Users who know, that file upload is enabled for them can then enable it. A comment in the config should document, that Users should know what they're doing.
Nevertheless, this is an annoying issue. :-\
Regards, Garvin.
Hi Garvin & list,
-----Original Message----- From: Garvin Hicking
I don't see why users shouldn't be able to use a function only because a hoster forbids the function to see whether a function is available.
This is not the case here since "function_exists" is enabled. The problem is that, in php versions before 4.3.0, this function does not check wheather the function is enabled. The hoster can't do anything but upgrading php.
Regards,
Alexander M. Turek alex@bugfixes.info
+-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
Garvin Hicking wrote:
Hi!
So we could put the @ in front of the 2 ini_get calls, as suggested in the bug report, but this means they won't be able to upload. I smell a new faq entry about upgrading their PHP:)
Can't we put an override file_upload directive in the configuration? I don't see why users shouldn't be able to use a function only because a hoster forbids the function to see whether a function is available. Users who know, that file upload is enabled for them can then enable it. A comment in the config should document, that Users should know what they're doing.
Nevertheless, this is an annoying issue. :-\
Regards, Garvin.
So, another suggestion. We reverse the logic of this part of code.
If we cannot detect that file uploads are disabled, we set $is_upload to TRUE.
Marc
Hi Marc!
So, another suggestion. We reverse the logic of this part of code.
If we cannot detect that file uploads are disabled, we set $is_upload to TRUE.
No, that's not really what I meant. I just wanted to propose, let the user choose via $cfg[] option to override any autodetections for $is_upload. Like this:
$cfg['OverrideUpload'] = FALSE; // If set to TRUE, you can choose to override auto-detection of your PHP's ability to allow file uploads and ENABLE them by all means. Some PHP-installations permit the auto-detection function (ini_get) because of security issues so phpMyAdmin is not able to see, if you can or cannot use file uploads. WARNING: If your PHP installation is not able to allow file uploads, you will definitely get errors and warnings when setting this to true.
Should also beat any existing records for the longest variable comment. ;-))
Regards, Garvin.
Garvin Hicking wrote:
Hi Marc!
So, another suggestion. We reverse the logic of this part of code.
If we cannot detect that file uploads are disabled, we set $is_upload to TRUE.
No, that's not really what I meant. I just wanted to propose, let the user choose via $cfg[] option to override any autodetections for $is_upload. Like this:
$cfg['OverrideUpload'] = FALSE; // If set to TRUE, you can choose to override auto-detection of your PHP's ability to allow file uploads and ENABLE them by all means. Some PHP-installations permit the auto-detection function (ini_get) because of security issues so phpMyAdmin is not able to see, if you can or cannot use file uploads. WARNING: If your PHP installation is not able to allow file uploads, you will definitely get errors and warnings when setting this to true.
Should also beat any existing records for the longest variable comment. ;-))
Regards, Garvin.
Garvin,
I know it's not what you meant, that's why I said "another suggestion". I don't think that we should add another config variable to workaround a PHP bug. Config variables add to complexity, and most users don't read the doc.
The current is_upload philosophy avoids displaying the file selector if we cannot detect that uploads are allowed. So if we reverse the logic, we will avoid displaying the file selector if we detect that uploads are not allowed, and sometimes (where PHP is < 43000 and ini_get() is not available), we will display a file selector that won't work. I think that this is acceptable.
Marc
Hi Marc!
I know it's not what you meant, that's why I said "another suggestion".
Ah, now I get it. I'm sorry for my misinterpretation. :)
The current is_upload philosophy avoids displaying the file selector if we cannot detect that uploads are allowed. So if we reverse the logic, we will avoid displaying the file selector if we detect that uploads are not allowed, and sometimes (where PHP is < 43000 and ini_get() is not available), we will display a file selector that won't work. I think that this is acceptable.
I agree with your notion against a new configuration directive. Just a question: Haven't there been issues with enabled is_upload, where the form got screwed up because of the form/form-data enctype attribute? Were there only certain php-installations affected? I don't remember...
Regards, Garvin.
Garvin Hicking wrote:
Hi Marc!
I know it's not what you meant, that's why I said "another suggestion".
Ah, now I get it. I'm sorry for my misinterpretation. :)
The current is_upload philosophy avoids displaying the file selector if we cannot detect that uploads are allowed. So if we reverse the logic, we will avoid displaying the file selector if we detect that uploads are not allowed, and sometimes (where PHP is < 43000 and ini_get() is not available), we will display a file selector that won't work. I think that this is acceptable.
I agree with your notion against a new configuration directive. Just a question: Haven't there been issues with enabled is_upload, where the form got screwed up because of the form/form-data enctype attribute? Were there only certain php-installations affected? I don't remember...
Regards, Garvin.
Garvin, There was this thread: https://sourceforge.net/forum/forum.php?thread_id=816587&forum_id=72909
maybe this was the same problem that duplicate fields (Apache config error), I don't remember if we got confirmation about this.
Marc
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle -
Rabus