Bug 16690 - Improve security of remote database installations
Summary: Improve security of remote database installations
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Installation and upgrade (command-line installer) (show other bugs)
Version: Main
Hardware: All All
: P5 - low major
Assignee: Mark Tompsett
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 17237
  Show dependency treegraph
 
Reported: 2016-06-07 23:44 UTC by Mark Tompsett
Modified: 2020-06-04 20:32 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Medium patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 16690: SHOW GRANTS fails to detect proper permissions (2.81 KB, patch)
2016-06-08 02:54 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Follow up etc/koha-conf.xml (1.00 KB, patch)
2016-07-07 07:12 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: SHOW GRANTS fails to detect proper permissions (2.39 KB, patch)
2017-07-06 13:31 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Follow up etc/koha-conf.xml (1.01 KB, patch)
2017-07-06 13:31 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Simplify and correct the SHOW GRANTS (3.09 KB, patch)
2018-04-19 01:05 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Make DB_HOST environment variable override. (2.67 KB, patch)
2018-04-19 01:21 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Simplify SHOW GRANTS to work when connected (8.59 KB, patch)
2018-04-25 16:40 UTC, Mark Tompsett
Details | Diff | Splinter Review
Bug 16690: Simplify SHOW GRANTS to work when connected (8.67 KB, patch)
2018-09-24 16:08 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 16690: Simplify SHOW GRANTS to work when connected (8.83 KB, patch)
2018-09-30 22:19 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Tompsett 2016-06-07 23:44:53 UTC
KohaDB: 192.168.71.250

> CREATE DATABASE koha_ils;
> GRANT ALL ON koha_ils.* TO 'kohauser'@'192.168.71.251' IDENTIFIED BY 'kohapass';
> FLUSH PRIVILEGES;
> QUIT;

KohaApp: 192.168.71.251
Do an install.
Hack the kohaconf username, hostname, passwords to match.
Try to run the web install steps.
You will get told you don't have enough permissions.
Why? Because 'hostname' is 192.168.71.250 to connect to the DB, but the app server is 192.168.71.251, and you should be checking against those GRANTS in installer/install.pl around line 116.

Hacked in a <webserver> tag to the kohaconf
and used that value instead in the script. Everything works.
Comment 1 Mark Tompsett 2016-06-08 02:54:09 UTC
Created attachment 52174 [details] [review]
Bug 16690: SHOW GRANTS fails to detect proper permissions

If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
This makes it so that you can specify the web and db server
separately, so the SHOW GRANT will match the machine the
user is connected from and return properly.
Comment 2 Frédéric Demians 2016-06-15 10:36:55 UTC
Since you add a new parameter to:

  debian/templates/koha-conf-site.xml.in

shouldn't it also added to:

  etc/koha-conf.xml
Comment 3 Mark Tompsett 2016-07-07 07:12:43 UTC
Created attachment 53162 [details] [review]
Bug 16690: Follow up etc/koha-conf.xml

As per Frédéric Demians feedback in comment #2,
made same changes to etc/koha-conf.xml as was made
to debian/templates/koha-conf-site.xml.in
Comment 4 Jonathan Druart 2017-04-19 12:28:22 UTC Comment hidden (obsolete)
Comment 5 Jonathan Druart 2017-04-19 12:28:55 UTC
Signed-off-by line is missing.
Dilan please adds it or at least let a comment to explicitly tell that you tested the patch and confirmed it works as expected.
Comment 6 Mark Tompsett 2017-07-06 13:31:35 UTC
Created attachment 64847 [details] [review]
Bug 16690: SHOW GRANTS fails to detect proper permissions

If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
This makes it so that you can specify the web and db server
separately, so the SHOW GRANT will match the machine the
user is connected from and return properly.
Comment 7 Mark Tompsett 2017-07-06 13:31:38 UTC
Created attachment 64848 [details] [review]
Bug 16690: Follow up etc/koha-conf.xml

As per Frédéric Demians feedback in comment #2,
made same changes to etc/koha-conf.xml as was made
to debian/templates/koha-conf-site.xml.in
Comment 8 Katrin Fischer 2017-10-28 12:23:03 UTC
Patches still apply. Mark, could you add a test plan please and say something about the requirements in order to test this?
Comment 9 Mark Tompsett 2017-11-02 01:10:43 UTC
(In reply to Katrin Fischer from comment #8)
> Patches still apply. Mark, could you add a test plan please and say
> something about the requirements in order to test this?

This is about the koha-create --use-db method, if doing a manual install from source. But I figure you can get the same result with a simple package install and a couple tweaks.

As you can see in comment #1, I created a DB, but did not grant permissions for '%'. This means when the web installer attempts to SHOW GRANTS it is going to fail, because hostname on a regular install is the KohaApp VM, not the KohaDB VM.

The 'Do an install' is a simple package installation.
'Hack the kohaconf...' is something like:
$ sudo vi /etc/koha/sites/library/koha-conf.xml
and making the appropriate adjustments to match the information used in the GRANT ALL.
Comment 10 Mark Tompsett 2018-04-03 03:59:23 UTC
Increased importance, because I really feel the local install of the DB on the same machine as the web server is not something larger enterprises wish to do.
Comment 11 Mark Tompsett 2018-04-18 23:06:46 UTC
I'm having difficulty retesting my own patch, so I've changed the status back to ASSIGNED, while I looking into this. I blame plack. ;)
Comment 12 Mark Tompsett 2018-04-18 23:58:56 UTC
Oooooo... CURRENT_USER is ANSI 1999. Anyone object to simpler code? :)
Comment 13 Mark Tompsett 2018-04-19 01:05:12 UTC
Created attachment 74510 [details] [review]
Bug 16690: Simplify and correct the SHOW GRANTS

MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.
Comment 14 Mark Tompsett 2018-04-19 01:21:04 UTC
Created attachment 74511 [details] [review]
Bug 16690: Make DB_HOST environment variable override.

Actually use __WEBSERVER_HOST__ in rewrite-config.PL
Comment 15 Mark Tompsett 2018-04-25 16:40:02 UTC
Created attachment 74849 [details] [review]
Bug 16690: Simplify SHOW GRANTS to work when connected

If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
Unless the DB is set up with 'user'@'%', which is also a
potential security issue.

MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.

This also removes the need to have permissions for
'koha_kohadev'@'%', because the only process to be
accessing the koha DB is from a known host/ip.
This tightens security too.

TEST PLAN
---------
Install 2 fresh VMs from a Debian ISO.
Make sure they are on the same network (192.168.50.x) as
the kohadevbox. You will need to remember one as DB_IPADDRESS.

On the DB VM & Third VM:
sudo apt-get install mariadb-server mariadb-client net-tools
-- the third vm just needs to be able to run mysql to access
   the DB VM.

On DB VM:
sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
-- make sure the bind-address line is commented out with a #
sudo service mariadb restart
-- congratulations, your DB server is listening to remote
   calls now.

sudo mysql -u root
CREATE DATABASE koha_kohadev;
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- now you have an empty DB ready to run a web install on.
   However, because only koha_kohadev from localhost is
   allowed, we expect failure when we try to run the web
   installation step when we get there.

Let's confirm that everything is working as expected
before trying.  It will also demonstrate the reason why
this patch is superior to the existing code.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should be denied

On DB VM:
DROP USER 'koha_kohadev'@'localhost';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case requires the unless code currently in place,
   because we aren't checking CURRENT_USER.

On DB VM:
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case demonstrates that we have two failure points:
       1) The GRANT command by the DB Admin and
       2) The koha-conf.xml setting.
   This is why CURRENT_USER is superior: only (2) is the
   failure point.

On DB VM:
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SELECT host,user FROM mysql.user;
-- Should see both koha_kohadev for 192.168.50.10 and %.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case doesn't need the unless. CURRENT_USER still
   just works.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

On DB VM:
DROP USER 'koha_kohadev'@'192.168.50.10';
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- This basically give koha_kohadev free reign to do pretty
   dangerous stuff.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show a line based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give a no such grant error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

In the old code, both cases were literally checked.
This tweak is an optimization which doesn't require
setting permissions to the mysql.user table. Without it,
the code says the user doesn't have permissions to check
the show grants.  This issue is not visible to the user,
because both cases are checked.

On DB VM:
SELECT host,user FROM mysql.user;
-- for each one do an appropriate DROP USER 'user'@'host';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';

On kohadevbox:
-- Make sure the /etc/koha/sites/kohadev/koha-conf.xml
   points to the DB VM.
-- Make sure a web install runs correctly

On third VM:
-- Make sure unable to connect as koha_kohadev/password.
Comment 16 Martin Renvoize (ashimema) 2018-09-24 16:08:27 UTC
Created attachment 79325 [details] [review]
Bug 16690: Simplify SHOW GRANTS to work when connected

If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
Unless the DB is set up with 'user'@'%', which is also a
potential security issue.

MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.

This also removes the need to have permissions for
'koha_kohadev'@'%', because the only process to be
accessing the koha DB is from a known host/ip.
This tightens security too.

TEST PLAN
---------
Install 2 fresh VMs from a Debian ISO.
Make sure they are on the same network (192.168.50.x) as
the kohadevbox. You will need to remember one as DB_IPADDRESS.

On the DB VM & Third VM:
sudo apt-get install mariadb-server mariadb-client net-tools
-- the third vm just needs to be able to run mysql to access
   the DB VM.

On DB VM:
sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
-- make sure the bind-address line is commented out with a #
sudo service mariadb restart
-- congratulations, your DB server is listening to remote
   calls now.

sudo mysql -u root
CREATE DATABASE koha_kohadev;
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- now you have an empty DB ready to run a web install on.
   However, because only koha_kohadev from localhost is
   allowed, we expect failure when we try to run the web
   installation step when we get there.

Let's confirm that everything is working as expected
before trying.  It will also demonstrate the reason why
this patch is superior to the existing code.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should be denied

On DB VM:
DROP USER 'koha_kohadev'@'localhost';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case requires the unless code currently in place,
   because we aren't checking CURRENT_USER.

On DB VM:
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case demonstrates that we have two failure points:
       1) The GRANT command by the DB Admin and
       2) The koha-conf.xml setting.
   This is why CURRENT_USER is superior: only (2) is the
   failure point.

On DB VM:
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SELECT host,user FROM mysql.user;
-- Should see both koha_kohadev for 192.168.50.10 and %.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case doesn't need the unless. CURRENT_USER still
   just works.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

On DB VM:
DROP USER 'koha_kohadev'@'192.168.50.10';
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- This basically give koha_kohadev free reign to do pretty
   dangerous stuff.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show a line based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give a no such grant error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

In the old code, both cases were literally checked.
This tweak is an optimization which doesn't require
setting permissions to the mysql.user table. Without it,
the code says the user doesn't have permissions to check
the show grants.  This issue is not visible to the user,
because both cases are checked.

On DB VM:
SELECT host,user FROM mysql.user;
-- for each one do an appropriate DROP USER 'user'@'host';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';

On kohadevbox:
-- Make sure the /etc/koha/sites/kohadev/koha-conf.xml
   points to the DB VM.
-- Make sure a web install runs correctly

On third VM:
-- Make sure unable to connect as koha_kohadev/password.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 17 Martin Renvoize (ashimema) 2018-09-24 16:10:36 UTC
Nice thorough test plan, all works as expected here.  Signing Off
Comment 18 Jonathan Druart 2018-09-30 22:19:17 UTC
Created attachment 79662 [details] [review]
Bug 16690: Simplify SHOW GRANTS to work when connected

If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
Unless the DB is set up with 'user'@'%', which is also a
potential security issue.

MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.

This also removes the need to have permissions for
'koha_kohadev'@'%', because the only process to be
accessing the koha DB is from a known host/ip.
This tightens security too.

TEST PLAN
---------
Install 2 fresh VMs from a Debian ISO.
Make sure they are on the same network (192.168.50.x) as
the kohadevbox. You will need to remember one as DB_IPADDRESS.

On the DB VM & Third VM:
sudo apt-get install mariadb-server mariadb-client net-tools
-- the third vm just needs to be able to run mysql to access
   the DB VM.

On DB VM:
sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
-- make sure the bind-address line is commented out with a #
sudo service mariadb restart
-- congratulations, your DB server is listening to remote
   calls now.

sudo mysql -u root
CREATE DATABASE koha_kohadev;
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- now you have an empty DB ready to run a web install on.
   However, because only koha_kohadev from localhost is
   allowed, we expect failure when we try to run the web
   installation step when we get there.

Let's confirm that everything is working as expected
before trying.  It will also demonstrate the reason why
this patch is superior to the existing code.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should be denied

On DB VM:
DROP USER 'koha_kohadev'@'localhost';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case requires the unless code currently in place,
   because we aren't checking CURRENT_USER.

On DB VM:
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case demonstrates that we have two failure points:
       1) The GRANT command by the DB Admin and
       2) The koha-conf.xml setting.
   This is why CURRENT_USER is superior: only (2) is the
   failure point.

On DB VM:
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SELECT host,user FROM mysql.user;
-- Should see both koha_kohadev for 192.168.50.10 and %.

On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case doesn't need the unless. CURRENT_USER still
   just works.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

On DB VM:
DROP USER 'koha_kohadev'@'192.168.50.10';
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- This basically give koha_kohadev free reign to do pretty
   dangerous stuff.

On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show a line based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give a no such grant error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
   administrator would prefer. And notice, CURRENT_USER still
   just works.

In the old code, both cases were literally checked.
This tweak is an optimization which doesn't require
setting permissions to the mysql.user table. Without it,
the code says the user doesn't have permissions to check
the show grants.  This issue is not visible to the user,
because both cases are checked.

On DB VM:
SELECT host,user FROM mysql.user;
-- for each one do an appropriate DROP USER 'user'@'host';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';

On kohadevbox:
-- Make sure the /etc/koha/sites/kohadev/koha-conf.xml
   points to the DB VM.
-- Make sure a web install runs correctly

On third VM:
-- Make sure unable to connect as koha_kohadev/password.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I have not followed the whole test plan but trusting author and SO
Changes make sense to me
Comment 19 Nick Clemens (kidclamp) 2018-10-01 16:40:16 UTC
Awesome work all!

Pushed to master for 18.11
Comment 20 Martin Renvoize (ashimema) 2018-10-05 11:58:17 UTC
Pushed to 18.05.x for 18.05.05
Comment 21 Fridolin Somers 2018-10-11 12:38:42 UTC
Pushed to 17.11.x for 17.11.11