We have left database security as a more or less untouched topic for too long and I hope to push that forward in the next weeks.
Good practice is to set a proper DB root password as well as add a less privileged account for the actual application. If we go that route we’d need to ask the user for two distinct new passwords or generate those and display to the user. We need a hint that those should be stored in the password manager of choice or written down. But as well I feel that we should prepare a detailed wiki article on how to reset the DB root password on all distros just in case people have locked themselves out. Who’s up for that?
I intend to use
mysql_secure_installationcommand as well.
In case people choose to let the installer generate a password I’d prefer to set a semi complex password (numbers, lower case, upper case and a couple special characters) but only 8 characters in length. That way we have a chance that people actually note it down. -> Not sure if that’s a great idea, open for discussion.
I’ll probably need to setup a whole park of VMs to test the changes before we actually release this to the public. Otherwise we’ll have a massive storm of questions in the forums and installations to fix up later on I fear. This is because we have different versions of MySQL/MariaDB in the distros and some behave differently as far as I know. We have @Wayne-Workman’s awesome installer test park running but I have a feeling that we won’t cover it all with that. We need fresh install testing but even more we need testing on upgrade installations (one with empty root password and another one with a password already set). I think I can do a fair bit of that in my VM test setup I have on my working laptop using snapshots. But I am not sure I can do it for all distros. @Moderators @Testers Anyone around who’d do the tests for one or the other distro?
Please post here if you have more ideas on this or if I have left out something important!!
Issues that we might run into as setting the password has changed several times in different versions of MySQL and MariaDB:
- MariaDB >10.4: https://www.reddit.com/r/sysadmin/comments/avx1u6/how_to_change_the_root_password_with_mariadb_104/ (“As a result of the above changes, the open-for-everyone all-powerful root account is finally gone. […] Using unix_socket means that if you are the system root user, you can login as root@locahost without a password.”)
- MariaDB =10.3.15 (Debian 10):
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY "your-password";works, tested 25.07.19 (ref)
Starting to collect information on password setting mechanisms for different versions of MySQL and MariaDB in the initial topic description. Please post here if you know of other things.
@hostjinni What does the external link have to do with FOG? This seems to be a company and we don’t fancy linking to external pages that don’t actually relate to this project!
hostjinni last edited by Sebastian Roth
Yes, very well said about DB root password. We must set very high security with database. There are some most trusted web hosting company in India but we should keep very strong DB security.
I’ll definitely pick this up again in the next days and weeks. Just had so many other things around and couldn’t find the time for this.
As well on github we have someone reporting a related issue. The installer doesn’t care about you typing in a password. It just wouldn’t use this when setting up the database in a lot of cases. Will be working on this as well: https://github.com/FOGProject/fogproject/issues/319
Wayne Workman last edited by
@developers @moderators I was able to get the daily installation tests to test upgrading from FOG 1.5.5. Mostly this is going good, but 1.5.5 didn’t install correctly on Fedora 30 or RHEL7. Those two are totally jacked, but everything else seems to be working right.
I need to write some new scripts to make the setup more easy though.
Wayne Workman last edited by Wayne Workman
It’s probably going to be two weeks or longer before I can adjust the daily tests - I’m super busy this weekend, next week, and vacation is the week after. But I’m pretty confident I can test upgrades. At least upgrading from the last release.
Wayne Workman last edited by
I’ve thought about testing upgrades, I don’t think it’d be too tough. Basically, I’d add 6 more instances - all the same OSs already being tested. But I’d install the last release of FOG on them - and then snapshot.
That way, the original 6 still have clean snapshots and would be labeled as ‘clean’, and the other 6 would have a fog installation on them and be labeled as ‘upgrade’. All the other commands remain the same I think.
Just a couple of thoughts of the top of my head.
- For the root password in the db. By default pick a random password and then give the user the option to change it, akin to how the fog installer picks the network adapter, but then lets the user change it. The fog installer should warn the user to write this password down someplace because its important and would be needed for database repair.
fogdbuser’s password should be managed like the
fogprojectlinux user’s password. Its owned and set by the fog installer, but is recorded in the .fogsettings file. If the
fogdbuser’s owns the fog db, then there really is never a reason to use the db’s
rootuser any more.
- For the db’s
rootuser password resets, I don’t think we need to reinvent the wheel here. Maybe provide a wiki with examples for the big three centos, debian, and ubuntu (current minus 2 releases if there is any changes) and then say for other distros they will need to google the answer. Lets not kill our selves trying to be all things to everyone. If the fog admin has deviated from the recommended distros then they should have enough skills to reset the root password. Its not that complicated.