hardcoded mysql credentials in postinst

[petiepooo]

I've located mysql root user dependencies in this package as well. See Security-Onion-Solutions/securityonion-elsa-extras#14 for additional details.

My question for this package is that I'm finding several instance of the following structure:

# check mysql password requirements
MYSQL_NO_PASSWORD=""
echo "quit" | mysql -u root 2>/dev/null && MYSQL_NO_PASSWORD=yes

# ... build .sql file here ...    

# execute SQL script
if [ -z "$MYSQL_NO_PASSWORD" ]
then
    echo
    echo "Removing the tables requires the password of the database root user"
    mysql -u root -p < /tmp/drop_sguil_db.sql
else
    mysql -u root < /tmp/drop_sguil_db.sql
fi

For these, it looks like the scripts already accommodate having a password set for mysql root user. Do I leave them alone and let it prompt for the root user when needed, or do I switch them to pull the debian_sys_maint user credentials and use that user instead, thereby tying these scripts to debian/ubuntu systems?

I'm leaning towards leaving them alone. If a user has root shell access needed to run these scripts, they know or can recover the mysql root password. These operations involve adding, clearing, and removing the sguil DB tables, which is an advanced feature, implying the user knows their way around their system already.

[dougburks]

I'm OK with tying these scripts to debian/ubuntu systems.

I'd recommend switching them to pull debian_sys_maint user credentials for consistency.

Thanks!

[petiepooo]

Ok. I'm swamped at work for a while, but will see if this is something I can do while traveling next week.

[dougburks]

Sounds good, thanks Pete!

[dougburks]

commit:
9448834