vicinas host in the mysql.user table?

[VFRDavid]

I have checked on three different systems that I do some support work for - and all three, which are running different versions of VICIdial, different SVN numbers and installed from different ISO's have two blank users with no passwords in the mysql.user table (plus similar entries in the mysql.db table) - one has "vicinas" in the host column, and the other has "localhost". I Googled "vicinas" - and found nothing "VICIdial" related in the search results - at least not within the first few search result pages.

Not sure how important this is, but...

System 1 Info:
MySQL (MariaDB) version(): 10.2.18-MariaDB-log
ViciBox: v.8.1.2 181002
Vicidial Version 2.14-721a Build 191015-1620
SVN: 3149 / DB Schema 1577

System 2 Info:
MySQL version: 10.2.17-MariaDB-log
ViciBox: v.8.1.0 180922
Vicidial Version: 2.14-721a BUILD: 191015-1620
SVN: 2973 / DB Schema 1542

System 3:
MySQL: 10.1.6-MariaDB-log
ViciBox: v.7.0.2-160325
Vicidial Version: 2.14-704a BUILD: 190312-0928
SVN: 3076 / DB Schema 1566

Anyway - I read that the blank users are there to give full access to the "test" databases (which the mysql.db table seems to confirm), they're not necessary, and that some (non-vici, MariaDB reliant) system installs actually remove them during their install routine.

So - I guess I am just curious if there is any reason to leave them there - or - if there is anything I missed in the documentation / best practices wise that would have avoided their creation in the first place - or that say I should be removing them manually before putting my system into production? Do they pose any security threat to the system or other databases in general (other than potentially allowing someone malicious access to the test database, if they also had access to my public IP address, where they could quickly use up all of my available disk space with looping INSERTs using a SELECT from the table they're inserting into, or some other such "playful" dark deed)??

I (most likely) would have just removed them without asking - had it not been for the "vici" in "vicinas" - but that made me think it could be on purpose - even if it (thankfully) doesn't appear to allow access to the asterisk DB.

Thanks for any feedback...appreciate it!

David

[williamconley]

I don't remember any reference to either of them, plus removal of the test database is a standard AND if you have a properly whitelisted system you wouldn't be quite so nervous. lol.

That being said: one way to test the "usage" of something in the Vicidial world is this:

Code: Select all

cd /usr/src/astguiclient/trunk/
grep vicinas * -Rin

Which appears to verify that there's no use of this string anywhere within the Vicidial code.

[VFRDavid]

Thanks for the reply...

I am pretty sure that I have it properly white-listed - I guess nothing is completely bullet proof though... One thing I do that I haven't seen documented is - in addition to changing the MySQL root users' password, I lock down the cron/other support users to only be able to login to the DB from their actual server-cluster IP addresses (e.g. I replace the `cron`@`%` user with `cron`@`111.222.33.44` for each Web/Agent/Telephony server in the cluster) - since I don't want anyone with a MySQL app logging in from their white-listed offices' address...even if they have just the default cron/1234 SELECT level access - that would be bad enough. I don't think I've ever seen that in the "best practices" that I've read - but ... IMHO ... if it isn't there - either this should be - or instructions on how to securely change the cron users' passwords...

Thanks again - the main reason it caught my eye was because of the "vici" in the host-name - thought it was curious...


David