SASL (Simple Application and Security Layer) is the method used to secure data in LSMCD and Memcached. There are various subtle differences in configuration between the two. This section describes the configuration you need to perform to allow LSMCD to operate in a SASL environment.
Enabling SASL is database wide. Once SASL is enabled, all non-SASL databases will need to be regenerated. This is only necessary if you ran LSMCD without SASL. Regeneration is done by deleting the files stored in the Cached.ShmDir parameter of your node.conf file (defaults /dev/shm/lsmcd) and allow them to be recreated. You will also need to regenerate your databases if you wish to remove SASL.
You can also secure data by user using SASL. See LSMCD Secure User Data Using SASL for details.
As for Memcached, if you enable SASL, text telnet commands will no longer work as there is no security mechanism in telnet. The client program memcapable will fail all tests as it does not properly handle SASL. If you wish to use this program to validate functionality, a customized version of the program is available in the distribution and can be built using instructions specified in the README.
To allow existing programs to run with SASL enabled, the Anonymous user, described in LSMCD Secure User Data Using SASL will allow ASCII and telnet access to an independent data area.
There are a number steps to configuring LSMCD to operate with SASL:
node.conf file.This is discussed in LSCMD Configuration, which also discusses overall configuration.
In particular you need to specify in your node.conf file:
CACHED.USESASL=TRUE
Note that once SASL is enabled, all failed accesses to Memcached functions are going to result in an error being written to the lsmcd log (defaults to /tmp/lsmcd.log). As mentioned above, ASCII and telnet commands are also going to fail as well (unless the Anonymous user feature is enabled).
When you change this value, accesses to the existing LSMCD database will fail as the system will detect a mismatch between your prior SASL configuration and your current one. You will need to delete your LSMCD data files:
rm -rf /dev/shm/lsmcd
A user database is required. The recommended method uses Cyrus SASL to create a sasldb managed database. Note that you become the security administrator for these accounts.
A sasldb database is typically stored in /etc/sasldb2 and is managed using the saslpasswd2 program. You must be root to manage users with saslpasswd2.
To create a user named user1 enter saslpasswd2 user1. You will be prompted for the password twice for that user. That information will then need to be coded in your memcached program. Details on the use of saslpasswd2 can be found in numerous places on the internet including gsp.com.
You can use either the simple user name or the realm qualified name visible in sasldblistusers2 (the name with the @hostname appended to it). Note that for user managed data it will use the name specified (which means the realm qualified and unqualified names will be separate).
The sasldb database must have permissions which allow the LSMCD user read access to it (typically 640 in most environments). Since this allows read access to any user in the root group, this may not meet your security requirements. This can be circumvented by creating a SASL managed database which is accessible only to the LSMCD user.
As above you will use the saslpasswd2 program. However, specify a database name with the `-f` parameter. For example, to create a user `user1` in the `/etc/sasllsmcd` database specify:
sudo saslpasswd2 -f /etc/sasllsmcd user1
Then you will want to make the database owned by the LSMCD user (`nobody` by default) and accessible only to that user:
sudo chown nobody:nobody /etc/sasllsmcd sudo chmod 600 /etc/sasllsmcd
The program `sasllistusers2` also supports the `-f` option.
To let LSMCD know of the database edit your /usr/local/lsmcd/conf/node.conf file and add the parameter: Cached.SaslDB. Assuming that the name of your new database is /etc/sasllsmcd add to node.conf:
Cached.SaslDB=/etc/sasllsmcd
The procedures for the Memcached extension to PHP are documented at php.net. You know you have it right if phpinfo displays a Memcached section.
The following is a sample PHP script you could create (named memcached.php) to validate that LSMCD is correctly installed and configured to work with SASL. You'll need to place it in the HTML directory of your server and adjust the user/password and other settings for your environment.
Some notes for all programming environments:
<?php
$mem_var = new Memcached();
$mem_var->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mem_var->setOption(Memcached::OPT_COMPRESSION, false);
$mem_var->setSaslAuthData('user', 'password');
$mem_var->addServer("127.0.0.1", 11211);
$response = $mem_var->get("SampleKey");
if ($response) {
echo "get(SampleKey) => " . $response;
} else if ($mem_var->getResultCode() == Memcached::RES_NOTFOUND) {
echo "Adding a key/value: SampleKey/SampleValue";
$mem_var->set("SampleKey", "SampleValue") or
die("SampleKey Couldn't be Created: '( " . $mem_var->getResultMessage() .
" )' ");
} else die ("Error in get: " . $mem_var->getResultCode() . ": " .
$mem_var->getResultMessage());
?>
Start LiteSpeed and LSMCD and point your browser to the web page you created. If the user or password are incorrect you'll see a message like Error in get: 41: AUTHENTICATION FAILURE. However if you have it right you'll see the first time you access the page Adding a key/value: SampleKey/SampleValue and subsequent accesses will show get(SampleKey) ⇒ SampleValue.
If you do not use the $mem_var→setSaslAuthData('user', 'password'); line, then this example will work for non-SASL environments as well.
There are a number of external classes for Python access to memcached. However, only the Python Binary Memcached client https://python-binary-memcached.readthedocs.io/ has been certified by LiteSpeed to work with LSMCD in SASL mode. Installation and use is fully described on their web site.