This section discusses briefly some security-related issues that you might want to think about as an administrator.
refdb tries to support the security features of MySQL as far as possible. This includes the username/password-based access rights scheme (not much surprise here). Since version 0.6.0 the passwords are no longer transmitted as plain text between the clients and the server. This means that it now makes sense to keep the passwords secret. There are several ways to specify the password when starting a refdb client. These ways differ with respect to the security of the passwords and are listed here in the order of increasing security:
The password is stored nowhere on the filesystem and thus pretty secure from this point of view. But the full command line can be viewed with the ps command by any user on the system, so the unencrypted password is basically world-readable at least for a very brief period until the applications have a chance to hide the string.
This way the password is protected from other users who habitually run the ps command just for the heck of it. But now it is stored unencrypted on the hard drive, and you must make sure that no one else can read the configuration file (no group or world read access).
This is the default behaviour if the password is not specified either in the configuration file or on the command line. The refdb client will ask for the password. This is certainly the most secure way to provide a password, but this won't work if you run the clients unattended via scripts.
It is beyond the scope of this manual to reiterate the MySQL security model (see the MySQL online manual), but you need to keep in mind a few aspects relevant to refdb.
MySQL security is based on the host from which you connect to the database server. This is partially circumvented by the refdb three-tier design. When adding users with the adduser command or manually with the mysql utility you have to specify the box where refdbd runs as the host, not the box from where the user will run the clients. This actually simplifies the user administration, but at the price of losing the fine control. There is currently no system in place for checking whether a client is allowed to connect to the refdbd application server from a particular host.
The refdba commands to remotely reconfigure a running application server are currently protected by a simple MySQL table access test. In any serious MySQL installation, only the administators have read access to the mysql.user table. The current implementation of this check requires that you have access to this table if you want to run the confserv commands. You should be aware that if the MySQL access rights are set up improperly, you may also allow everyone and their grandma to stop or reconfigure the refdbd application server. If you cannot restrict read access to mysql.user for whatever reason, you should not enable refdbd remote administration (default is off) and use the kill command or the refdbctl script instead.
Most of the refdba commands require database administrator rights.
If you install and run MySQL yourself, you should not use the default administrator account. The name (root) is widely known and by default this account is not password-protected. To make your database server secure, please create a new administrator account with a different name and specify a password.
Web access adds some security flaws to your system. Usernames and passwords will travel happily as plaintext between the browser and the web server. If you choose to store the access information as a cookie to simplify subsequent accesses, the username and password will be stored on the disk as plain text. It may be prudent to create special MySQL accounts with restricted access rights for use with the web interface.