Run zpanel without MySQL root

[MBlagui]

Remove mysql root off config file and place it a file that only hook will access.

Goal in case of panel direct hack Mysql root won't be exposed.

[Rakhmanov]

What config file are you speaking of? Very convoluted writing.

[allebb]

I assume Me.B is referring to the db.cnf file as seen here ( https://github.com/sentora/sentora-core/blob/master/cnf/db.php)

On 19 November 2014 08:46, Rakhmanov notifications@github.com wrote:

What config file are you speaking of? Very convoluted writing.

— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-core/issues/64#issuecomment-63608369.

[5050]

Can really this to be done ? If I understand well:

• you want that this file is not reachable in case of hack of the panel.
• it must be reachable in order to use the panel. These two points seems me to be mutually exclusive.

[allebb]

I know there are a number of ways this can be achieved eg. with variables in the PHP.ini file and environmental variables but to be honest these are all very dangerous... eg if someone can create a PHP script they only then need to call the environmental variables eg. echo getenv('mysql_root_pass') to get the result etc. of use phpinfo() function to return all PHP vars - I'm sure that if having the DB settings in a PHP include file was really all that bad then other, much larger projects such as Wordpress etc. would have implemented something different by now!

Maybe I'm missing something but I've worked with PHP for a very long time and I'm racking my brains at the moment to work out what the 'solution' here would be (one that is actually water-tight from all directions as there are pros and cons for all the alternatives that I've been thinking oft!)

Maybe I should Goolge lol!

On 19 November 2014 14:10, Pascal Peyremorte notifications@github.com wrote:

Can really this to be done ? If I understand well:

• you want that this file is not reachable in case of hack of the panel.
• it must be reachable in order to use the panel. These two points seems me to be mutually exclusive.

— Reply to this email directly or view it on GitHub https://github.com/sentora/sentora-core/issues/64#issuecomment-63644600.

[Rakhmanov]

If someone has access to your php files on server its too late to worry about mysql root password.

[TGates71]

Bobby is correct, using an include file IS the safest way of calling DB info and is the standard for ALL php/mysql sites around the world-why re-invent the wheel? Although, most of them use something like this to lock it down:

if (stristr(htmlentities($_SERVER['PHP_SELF']), 'config.php')) {
    Header('Location: index.php');
    die();
}

If the file is accessed directly it will die and redirect them to the index.php

[5050]

The test proposed by @TGates71 is even not required because the whole directory cnf is protected by a "deny from all" (apache 2.2) or "require all denied" (apache 2.4) placed in httpd.conf file (line 24)

Except if @MBlagui was thinking to something different, all is correct and nothing more can be done. I'll close this issue.

[TGates71]

As a side note, the above could be added as a secondary protection just in case a panel user screws up their deny statement (which I am sure will happen from time to time LOL)

[MBlagui]

My point here was:

1. Sentora panel don't need mysql root access for 99% of features. It need it only when creating a MySQL DB & MySQL user mainly.
2. MySQL should be considered as a ressource indeed & the long term goal would be to separate the core DB priviliges from the one needed to manage MySQL DB, so later we could almost use the same module for managing db to manage PostgreSQL or what ever DB adding few functions.
3. Locking down the panel and reducing privileges is important. Also Core DB could be hosted on another server and not rely on VPS/server own MySQL.

M B