Hi Loïc,
Do you mean you use "only_db" to skip to stuffs to get the table list? You don't rely on this feature as a way to define access rights to your MySQL server, isn't it?
No, rights are for mysql, no doubts in my head ;-)
BUT, 1) in advanced auth, 'only_db' can be an array of db so if rights are correctly set and 'only_db' too : I'm not sure I'm getting the problem ?! 2) much more important : in virtual hosting, you can't change mysql parameters : it's not advanced auth but the 'only_db' feature is really important in real life use of Pma in such environments.
Advanced auth is getting really a difficult problem (bookmark, only db ...) : maybe the config.inc.php3 should be split in two with a config_multi-user.inc.php3 much cleaner, maybe smarter and easy to administer.
Alain.
On Thu, 11 Oct 2001, Alain Brissaud wrote:
Advanced auth is getting really a difficult problem (bookmark, only db ...) : maybe the config.inc.php3 should be split in two with a config_multi-user.inc.php3 much cleaner, maybe smarter and easy to administer.
How about allowing an environment variable such as PMAMULTICONFIG that specifies what config_*.inc.php3 file should be used? That way multiple config files can be supported under the same codebase and the config file could be specified with SetEnv or in the Web Properties of whatnot.
Hello Alain.
- much more important : in virtual hosting, you can't change mysql
parameters :
it's not advanced auth but the 'only_db' feature is really important in
real
life use of Pma in such environments.
But that's the point exactly - it's not in the scope of pMA to handle MySQL security issues - if MySQL permissions aren't set correctly - then it's the administrator that's lazy - and it should not depend on pMA to set up "intended" permissions... pMA should not be a security shell layer above the MySQL Server...
So I defenitly don't hope that ISPs in VHost environments counts on pMA to set permissions solely based on the only_db feature of phpMyAdmin. That's really very wrong ... very very wrong...
So the question is not wheter pMA should be a security layer above the MySQL Server or not (because we - the developers - agree - at least until now - that we won't make security tighter in pMA than what's allowed by the MySQL permissions) - but a question about - does the only_db make any sence or not...
To all:
And I agree - when pMA is runned in a multihosting environment with perhaps 100's or 1000's of databases it's really important only to show allowed databases... So in my opinion - the use of only_db would be far more correct if it's a TRUE/FALSE variable - that tells pMA to check for permissions and only show allowed databases of the authenticated user. (and actually I think that MySQL has a feature that enables the same thing - that MySQL only shows allowed databases and tables to the client based on the authenticated user - I just can't find it in the documentation at this moment - but I'll keep searching :o)) ).
-- Kind regards Geert Lund
And I agree - when pMA is runned in a multihosting environment with perhaps 100's or 1000's of databases it's really important only to show allowed databases... So in my opinion - the use of only_db would be far more correct if it's a TRUE/FALSE variable - that tells pMA to check for permissions and only show allowed databases of the authenticated user. (and actually I think that MySQL has a feature that enables the same thing - that MySQL only shows allowed databases and tables to the client based on the authenticated user - I just can't find it in the documentation at this moment - but I'll keep searching :o)) ).
That a solution, but each time the left frame is refreshed, should we list again all the 1000 database and build only the one we have right to see (I see load on the server coming ;-) ). 'only db' is not so bad maybe with a smarter way a checking rights.
-
Alain Brissaud -
Geert Lund - SilverSoft Productions -
Ignacio Vazquez-Abrams