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