So, it's somewhat well known that Solus stores root passwords in its database schema. The reason that they're there is so that it can attempt to reset the root password when an OS reinstall is performed. This does not seem to work 100% of the time, making it more of a liability than a feature.
"But the passwords are encrypted/hashed/salted/voodoo magic/something!" you say. Sure, this is true. However, if the software can decrypt a password, so can an attacker. Therefore, to reduce liability, i've implemented a MySQL feature to automatically empty the 'rootpassword' column on our installation every 5 minutes.
From http://www.sitepoint.com/how-to-create-mysql-events/ :
An event is similar to a trigger. However, rather than running in response to a data change, events can be scheduled to run any number of times during a specific period. In effect, it’s a database-only cron job. Events have been supported in MySQL since version 5.1. They are ideal for maintenance tasks such as data archiving or report generation which can be scheduled during off-peak times.
Solus is using Mysql 5.1, so we can use events. You'll need to explicitly set the events engine to on, also from http://www.sitepoint.com/how-to-create-mysql-events/ :
MySQL events are executed by a special event scheduler thread. It’s disabled by default so use the following MySQL command can determine whether it’s running: SHOW PROCESSLIST; If the scheduler is running, at least two rows will be shown and one will have its user field set to “event_scheduler”. If only one row is returned, the scheduler is disabled and events will not run. You can ensure the scheduler starts when MySQL is launched with the command-line option --event-scheduler=ON or setting event_scheduler=ON in your MySQL configuration file (my.cnf or my.ini on Windows). Alternatively, you can start the scheduler from the MySQL command line: SET GLOBAL event_scheduler = ON;
Now that you've enabled the event handler, you can execute the following SQL for your Solus database:
NOTICE: This information is being offered for utilization on your own good judgement. I'm not responsible for data loss, angry clients, your dog being killed, etc. Make proper backups, and test the event handler on a separate database before committing it to your live database.
CREATE EVENT `ClearPWColumn` ON SCHEDULE EVERY 5 MINUTE STARTS '2013-03-01 00:00:01' ON COMPLETION PRESERVE ENABLE DO UPDATE vservers SET rootpassword = NULL
Every 5 minutes, MySQL will automatically set the contents of every row of the rootpassword column in the vservers table to NULL. This has the effect that, when the client reinstalls their OS, the install script will attempt to set the root password to an empty value, which is not allowed:
A demonstration:
[root@sapphire ~]# vzctl set 106 --userpasswd root: Running container script: /etc/vz/dists/scripts/set_userpass.sh Password change failed
Please note that on our installation, this does not result in containers with blank root passwords. Please add a step into your verification after implementation to ensure that on your installation, client containers aren't being installed with blank passwords.
The user will need to set their root password after reinstalling their OS, using the existing functionality in Solus. This method ensures that the client's selected root password only lives in the database for 5 minutes; if you need a more finite interval than this, you could reduce the event interval into the SECOND range, or use TRIGGER instead.