Hi,
At Debian we've gotten a bug report which I'm quoting below. Basically, the
user has hashing of his sessions dir, but this is appearently broken by the
following bit of code that phpMyAdmin employs in session.php:
// use more secure session ids (with PHP 5)
if (version_compare(PHP_VERSION, '5.0.0', 'ge')
&& substr(PHP_OS, 0, 3) != 'WIN') {
ini_set('session.hash_function', 1);
ini_set('session.hash_bits_per_character', 6);
}
As I understand it, only the first option actually changes the security, as it
increases the number of bits in the algorithm. Changing the
hash_bits_per_character option only changes the style of the session hash
names, not their security.
Yet, "hard" overriding this second option causes trouble for sysadmins that
have enabled hashing of their session dir as in the quoted bug report. I see
no real reason to hardcode the bits_per_character option, as the only thing
it does is make te ID's a bit shorter, but they're not human readable
anyway...
Is there a reason why bits_per_character is hardcoded, or could it be removed?
thanks,
Thijs
=== begin quote ===
Enabling hashing session files to directories[1] with default php
configuration requires creating a directory hierarchy[2] for them.
Phpmyadmin enforces different session names[3] than configured by
sysadmin, but does use default directory and hashing depth. So if
sysadmin creates hierarchy for his session naming scheme, phpmyadmin
will fail creating (some) of the session files because no directories
[G-Zg-z] (and maybe more?) exist in the directory tree.
IMO phpmyadmin should honor session settings in the main php.ini or
allow this behaviour to be configured by debconf (along with its own
session directory).
[1] accomplished by setting session.save_path="2;/var/lib/php5" in
/etc/php5/apache2/php.ini
- session name: sess_a1765f9b22bc2e2c2b672f4ab34a3199
- is stored as /var/lib/php5/a/1/sess_a1765f9b22bc2e2c2b672f4ab34a3199
[2] with default php setting sessions are hashed to hex-digit
directories (session.hash_bits_per_character = 4)
[3] /usr/share/phpmyadmin/libraries/session.inc.php:66 [in 2.9.1.1 -TK]
=== end quote ===
Welcome to phpMyAdmin 2.11.6, a bugfix-only version.
The release notes and download info are available on
http://www.phpmyadmin.net.
Marc Delisle, for the team.
Rekrutacja schrieb:
> Marc Delisle wrote:
>> Sebastian Mendel a écrit :
>>> Hi,
>>>
>>> Rekrutacja schrieb:
>>>> i've tested latest pma (phpMyAdmin-trunk-20080424-022001), and it seems
>>>> it has DisableIS set to true as default, but when i log in and click any
>>>> of the tables from database, i can see this on the server:
>>>>
>>>> SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING,
>>>> ACTION_STATEMENT, EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE FROM
>>>> information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA= 'test99_db' and
>>>> EVENT_OBJECT_TABLE = 'phpbb2_bookmarks'
>>>>
>>>> and is taking very long time, same as without DisableIS.
>>>>
>>>> does DisableIS is not yet fully implemented or is it a bug?
>>> 1. not fully implemented
>>> 2. IMHO sooner, later or already SHOW will mapped to I_S
>>> 3. the above statement should include TRIGGER_SCHEMA in WHERE
>>>
>>> Marc?
>>>
>>> was there any reason not including TRIGGER_SCHEMA in WHERE?
>>
>> The EVENT_OBJECT_SCHEMA seems to always have the same content as
>> TRIGGER_SCHEMA, but I just noticed that in the MySQL manual they suggest
>> using TRIGGER_SCHEMA in the WHERE clause as you suggested, so I merged
>> the change and the doc reference (for version 2.11.7)
>>
>> http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin/branches/QA_2_11/ph…
>>
>> Rekrutacja, is it faster this way on your server?
>
> i've tried latest 3.0-dev version, from svn (did checkout just few
> minutes ago), and it is still slow.
>
> Query | 30 | checking permissions | SELECT TRIGGER_SCHEMA,
> TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING, ACTION_STATEMENT,
> EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE FROM information_schema.TRIGGERS
> WHERE TRIGGER_SCHEMA= 'test99' and EVENT_OBJECT_TABLE = 'phpbb2_confirm'
whats your MySQL server version?
--
Sebastian Mendel
Hi,
Rekrutacja schrieb:
> i've tested latest pma (phpMyAdmin-trunk-20080424-022001), and it seems
> it has DisableIS set to true as default, but when i log in and click any
> of the tables from database, i can see this on the server:
>
> SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_MANIPULATION, ACTION_TIMING,
> ACTION_STATEMENT, EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE FROM
> information_schema.TRIGGERS WHERE EVENT_OBJECT_SCHEMA= 'test99_db' and
> EVENT_OBJECT_TABLE = 'phpbb2_bookmarks'
>
> and is taking very long time, same as without DisableIS.
>
> does DisableIS is not yet fully implemented or is it a bug?
1. not fully implemented
2. IMHO sooner, later or already SHOW will mapped to I_S
3. the above statement should include TRIGGER_SCHEMA in WHERE
Marc?
was there any reason not including TRIGGER_SCHEMA in WHERE?
--
Sebastian Mendel
Grande Oportunidade veja os detalhes !!!.
--------------------------------------------
Sandra!!.zip: Nao Tem Virus!
Norton AntiVirus Procura Progressiva
Mais detalhes: www.symantec.com
Hi,
Just a short report here. Robin Johnson and I were present at the
phpMyAdmin booth this year. I had not seen Robin since the first
developer meeting in 2005.
http://flickr.com/photos/lenzgr/2416227949/
We received many visitors, sometimes both of us were busy at the same
time! The majority of visitors did not know about features like the
Designer or inline display of photos in Browse mode. It seems that only
a few visitors were not already users of phpMyAdmin so we got a fair
number of "Thank you" for the product.
Marc Delisle
Two projects for phpMyAdmin improvement have been accepted in GSoC 2008.
Thanks to Google for this initiative, Colin Charles (MySQL/Sun) for the
offer of external mentorship and to Raj Kissu Rajandran and Piotr
Przybylski, the two students who will work on these projects.
http://code.google.com/soc/2008/mysql/about.html
Welcome to the first release candidate for phpMyAdmin 2.11.6, a
bugfix-only version.
The release notes and download info are available on
http://www.phpmyadmin.net.
Marc Delisle, for the team.