This section briefly discusses some security-related issues that you might want to think about as an administrator. We'll look at the access control provided by the external database servers MySQL and PostgreSQL.
Note: The embedded database engine SQLite does not provide built-in access control. All you can do is use chown and chmod to restrict access to the database files. There is no way to restrict access through refdb.
refdb tries to support the security features of the SQL database servers 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 security models of the database servers, but you need to keep in mind a few aspects relevant to refdb.
One component of the database server access control is based on the host from which you connect to the database server. This is partially circumvented by the refdb three-tier design. Keep in mind that only refdbd communicates with the database server. Therefore only the host where refdbd runs is relevant for the access 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.
Both MySQL and PostgreSQL distinguish between local and remote connections. Access needs to be granted separately if you want to use both local and remote connections
Note: On many operating systems the default installations of MySQL and PostreSQL do not allow remote connections for security reasons. You need to manually allow remote connections as described below.
The refdba commands to remotely reconfigure a running application server are currently protected by a simple table access test. In any serious database server installation, only the database administators have read access to certain system tables. 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 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 system tables 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 run MySQL as your database server, these things apply as well:
When adding users with the adduser command the -H option has to specify the box where refdbd runs as the host, not the box from where the user will run the clients. If you do not specify a host, "localhost" is assumed.
To allow remote connections to the database server, the MySQL configuration file my.cnf must not contain the option "skip-networking", and the start script must not use the command-line option --skip-networking. Many operating systems use one of these methods in default installations to restrict access to local users for security reasons.
If you install and run MySQL yourself, you should not use the default database 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 database administrator account with a different name and specify a password.
If you run PostgreSQL as your database server, these hints are for you:
The host-based part of the PostgreSQL access control is not accessible through the SQL interface. Therefore, the refdba command adduser cannot provide the host information (in other words, the -H is ignored).
Instead, the host-based part of the access control is specified in the PostgreSQL configuration file, usually /home/pgsql/data/pg_hba.conf. On most operating systems, the default configuration allows unrestricted access for all users on the local system, but no remote access. Use something like the following entries to enforce usage of passwords for both local access and remote access from the network 192.168.1.0 to refdb1 and a reference database "refs":
# host DBNAME IP_ADDRESS ADDRESS_MASK AUTH_TYPE [AUTH_ARGUMENT]
local refdb1 crypt
local refs crypt
host refdb1 192.168.1.0 255.255.255.0 crypt
host refs 192.168.1.0 255.255.255.0 crypt
|
As mentioned previously, only the host where refdbd runs is relevant for the host or network entries in the configuration file.
Make sure to read the PostgreSQL documentation to get your access control right.
Note: Please keep in mind that postmaster (the PostgreSQL database server parent process) needs to be started with the -i option to accept remote connections at all. Most default installations do not use this switch to increase security.
If you install and run PostgreSQL yourself, you should not use the default database administrator account. The name (pgsql) is widely known and by default this account is not password-protected. To make your database server secure, please create a new database 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 database accounts with restricted access rights for use with the web interface.