6 Mar
2003
6 Mar
'03
7:27 p.m.
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(a)bugfixes.info>
+-----------------------------+
| The phpMyAdmin Project |
| http://www.phpmyadmin.net |
| rabus(a)users.sourceforge.net |
+-----------------------------+
| [bugfixes.info] |
| http://www.bugfixes.info |
| rabus(a)bugfixes.info |
+-----------------------------+
8 Mar
8 Mar
6:33 a.m.
New subject: [Phpmyadmin-devel] disabled functions for security
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(a)bugfixes.info>
+-----------------------------+
| The phpMyAdmin Project |
| http://www.phpmyadmin.net |
| rabus(a)users.sourceforge.net |
+-----------------------------+
| [bugfixes.info] |
| http://www.bugfixes.info |
| rabus(a)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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
12:28 p.m.
New subject: [Phpmyadmin-devel] disabled functions for security
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.
1:03 p.m.
New subject: [Phpmyadmin-devel] disabled functions for security
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(a)bugfixes.info>
+-----------------------------+
| The phpMyAdmin Project |
| http://www.phpmyadmin.net |
| rabus(a)users.sourceforge.net |
+-----------------------------+
| [bugfixes.info] |
| http://www.bugfixes.info |
| rabus(a)bugfixes.info |
+-----------------------------+
4:38 p.m.
New subject: [Phpmyadmin-devel] disabled functions for security
Garvin Hicking wrote:
Hi!
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
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.
5:18 p.m.
New subject: [Phpmyadmin-devel] disabled functions for security
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.
9 Mar
9 Mar
5:38 a.m.
New subject: [Phpmyadmin-devel] disabled functions for security
Garvin Hicking wrote:
Hi Marc!
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
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.
6:30 a.m.
New subject: [Phpmyadmin-devel] disabled functions for security
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.
7:57 a.m.
New subject: [Phpmyadmin-devel] disabled functions for security
Garvin Hicking wrote:
Hi Marc!
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
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.
7862
days inactive
7865
days old
8 comments
4 participants
participants (4)
-
Alexander M. Turek -
Garvin Hicking -
Marc Delisle -
Rabus