Sebastian Mendel schrieb:
> with this feature implemented the sysadmin can choose, but I_S.SCHEMATA=
> much slower than I_S.SCHEMA_PRIVILEGES, cause privileges are in RAM, bu=
> 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=20
guess this would scale even worse than SCHEMATA. X-)
> cause I_S.SCHEMA_PRIVILEGES contains only databases with explicit privi=
> for the current users, not all, and as stated above I_S.SCHEMATA can be=
> 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=20
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=20
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=20
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=20
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 sh=
> 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=20
misconfiguration of misunderstood features. ;-)
Marc Delisle schrieb:
> See the various speed problems about information_schema here:
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=20
that branch is not GA, yet. But as 5.0 is affected, too, I fully agree=20
with the both of you. I surrender. ;-)