/usr/share/doc/refdb/refdb-manual/ch05s07.html is in refdb-doc 1.0.2-3ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Security issues</title><link rel="stylesheet" type="text/css" href="manual.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="home" href="index.html" title="RefDB handbook" /><link rel="up" href="ch05.html" title="Chapter 5. refdbd administration" /><link rel="prev" href="ch05s06.html" title="Logging data" /><link rel="next" href="ch05s08.html" title="How to run several refdb instances" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Security issues</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch05s06.html">Prev</a> </td><th width="60%" align="center">Chapter 5. refdbd administration</th><td width="20%" align="right"> <a accesskey="n" href="ch05s08.html">Next</a></td></tr></table><hr /></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp64576768"></a>Security issues</h2></div></div></div><p>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.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>The embedded database engine SQLite does not provide built-in access control. All you can do is use <span class="command"><strong>chown</strong></span> and <span class="command"><strong>chmod</strong></span> to restrict access to the database files. There is no way to restrict access through refdb.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp64580640"></a>Passwords</h3></div></div></div><p>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 (but you can request the old behaviour using the <code class="option">-x</code> command line options since version 1.0). 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 <span class="emphasis"><em>increasing</em></span> security:</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Specify the password on the command line</span></dt><dd><p>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 <span class="command"><strong>ps</strong></span> 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.</p></dd><dt><span class="term">Store the password in the personal configuration file</span></dt><dd><p>This way the password is protected from other users who habitually run the <span class="command"><strong>ps</strong></span> 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).</p></dd><dt><span class="term">Specify the password interactively</span></dt><dd><p>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.</p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="sect-database-server-access-control"></a>Database server access control</h3></div></div></div><p>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.</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>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.</p></li><li class="listitem"><p>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</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>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.</p></div></li><li class="listitem"><p>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 <a class="link" href="re06.html#app-a-command-confserv" title="confserv"><span class="command"><strong>confserv</strong></span></a> 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 <a class="link" href="ch12.html" title="Chapter 12. The application server"><span class="command"><strong>kill</strong></span> command</a> or the <a class="link" href="re01.html" title="refdbctl">refdbctl</a> script instead.</p></li><li class="listitem"><p>Most of the refdba commands require database administrator rights. </p></li></ul></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp64114160"></a>MySQL</h4></div></div></div><p>If you run MySQL as your database server, these things apply as well:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>When adding users with the <a class="link" href="re06.html#app-a-command-adduser" title="adduser"><span class="command"><strong>adduser</strong></span></a> command the <code class="option">-H</code> 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. This works on some platforms (e.g. FreeBSD 5.4), but not on others (e.g. Fedora Core 4). In the latter case you may have to specify the hostname explicitly.</p></li><li class="listitem"><p>To allow remote connections to the database server, the MySQL configuration file <code class="filename">my.cnf</code> must not contain the option "skip-networking", and the start script must not use the command-line option <code class="option">--skip-networking</code>. Many operating systems use one of these methods in default installations to restrict access to local users for security reasons.</p></li><li class="listitem"><p>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.</p></li></ul></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp64122320"></a>PostgreSQL</h4></div></div></div><p>If you run PostgreSQL as your database server, these hints are for you:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The host-based part of the PostgreSQL access control is not accessible through the SQL interface. Therefore, the refdba command <a class="link" href="re06.html#app-a-command-adduser" title="adduser"><span class="command"><strong>adduser</strong></span></a> cannot provide the host information (in other words, the <code class="option">-H</code> is ignored).</p><p>Instead, the host-based part of the access control is specified in the PostgreSQL configuration file, usually <code class="filename">/home/pgsql/data/pg_hba.conf</code>. 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 refdb and a reference database "refs":</p><pre class="programlisting"># host DBNAME IP_ADDRESS ADDRESS_MASK AUTH_TYPE [AUTH_ARGUMENT]
local refdb crypt
local refs crypt
host refdb 192.168.1.0 255.255.255.0 crypt
host refs 192.168.1.0 255.255.255.0 crypt
</pre><p>As mentioned previously, only the host where refdbd runs is relevant for the host or network entries in the configuration file.</p><p>Make sure to read the PostgreSQL documentation to get your access control right.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Please keep in mind that <code class="filename">postmaster</code> (the PostgreSQL database server parent process) needs to be started with the <code class="option">-i</code> option to accept remote connections at all. Most default installations do not use this switch to increase security.</p></div></li><li class="listitem"><p>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.</p></li></ul></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch05s06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch05s08.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Logging data </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> How to run several refdb instances</td></tr></table></div></body></html>
|