Hi there,
Sebastian Mendel schrieb:
with this feature implemented the sysadmin can choose, but I_S.SCHEMATA is much slower than I_S.SCHEMA_PRIVILEGES, cause privileges are in RAM, but for I_S.SCHEMATA a directory scan is done, and all database informations a collected (default charset, engine, aso.)
Hum, so MySQL does not cache this? Do you think, phpMyAdmin could/should cache the listing somehow (e.g. inside php's session container)? But I guess this would scale even worse than SCHEMATA. X-)
cause I_S.SCHEMA_PRIVILEGES contains only databases with explicit privileges for the current users, not all, and as stated above I_S.SCHEMATA can be much much slower them SHOW DATABASES or SHOW DATABASES LIKE '...'
So if I logged in as a root-like user, I wouldn't see any databases if we query SCHEMA_PRIVILEGES, would I?
why is this 'dangerous', it is up to the sysadmin,
Because this may appear like a privilege feature, while in fact the user may still see databases that have been hidden in our listing. If the feature is added, a warning about that issue should be added to the docs.
on most ISP installations there is no need for I_S to the user,
Sure, there is. Even if you are only allowed to access a single database, information_schema is useful to advanced users. Maybe we could auto-add it to the listing, if the admin's query hides it?
Hey, and don't tell me that most advanced users probably know how to access a hidden information_schema. ;-)
`test` is disabled from anonymous access, and all databases for the user start with a specific prefix
This is probably the case.
as this solution is mainly for ISPs and the default will still be SHOw DATABASES and i think ISPs take care what users can see and not this should not be a problem
All right then. But that has to be documented very well. I'm just afraid of phpMyAdmin being blamed for security holes introduces by misconfiguration of misunderstood features. ;-)
Marc Delisle schrieb:
See the various speed problems about information_schema here: http://bugs.mysql.com/bug.php?id=19588
I see. I didn't know about this issue. Probably because my MySQL servers don't have enough schemata to encounter it.
Even if it's fixed in 5.1.22, we don't plan to have 5.1.22 as a minimum MySQL version, do we?
If it would only affect the 5.1 branch, I would not work around it as that branch is not GA, yet. But as 5.0 is affected, too, I fully agree with the both of you. I surrender. ;-)
Regards,
Alexander