title: Secure command server access

h3. Secure command server access

h4. The problem

The command server provided by liquidsoap is very convenient for 
manipulating a running instance of liquidsoap. However, no authentication
mechanism are provided. 

The telnet server has no authentication and listens
by default on the localhost (@127.0.0.1@) network interface,
which means that it is accessible to any logged user on the machine.

Many users have expressed interest into setting up a secured access
to the command server, using for instance user and password information.
While we understand and share this need, we do not believe this 
is a task that lies into liquidsoap's scope.

An authentication mechanism is not something that should be implemented 
naively. Being SSH, HTTP login or any other mechanism, all these methods
have been, at some point, exposed to security issues. Thus, implementing
our own secure access would require a constant care about possible security
issues.

Rather than doing our own home-made secure acces, we believe that our users should be 
able to define their own secure access to the command server, taking advantage of a 
mainstream authentication mechanism, for instance HTTP or SSH login.

In order to give an example of this approach, we show here how to create
a SSH access to the command server.

h4. SSH access to the command server

In this section, we create a SSH user that, when logging through SSH, 
has only access to the command server. 

First, we enable the unix socket for the command server in liquidsoap:
%%
set("server.socket",true) 
set("server.socket.path","/path/to/socket")
%%
When started, liquidsoap will create a socket file @/path/to/socket@
that can be used to interact with the command server. For instance,
if your user has read and write rights on the socket file, you can do:
%%
socat /path/to/socket -
%%
The interface is then exactly the same has for the telnet server.

We define now a new "shell". This shell is in fact the invokation of the 
socat command. Thus, we create a @/usr/local/bin/liq_shell@ file with the following
content:
%%
#!/bin/sh
# We test if the file is a socket, readable and writable.
if [ -S /path/to/socket ] && [ -w /path/to/socket ] && \
   [ -r /path/to/socket ]; then
  socat /path/to/socket -
else
# If not, we exit..
  exit 1
fi
%%
We set this file as executable, and we add it in the list of shells in @/etc/shells@.

Now, we create a user with the @liq_shell@ as its shell:
%%
adduser --shell /usr/local/bin/liq_shell liq-user
%%
You also need to make sure that @liq-user@ has read and write rights
on the socket file.

Finally, when logging through ssh with @liq-user@, we get:
%%
11:27 toots@leonard % ssh liq-user@localhost
liq-user@localhost's password: 
Linux leonard 2.6.32-4-amd64 #1 SMP Mon Apr 5 21:14:10 UTC 2010 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Oct  5 11:26:52 2010 from localhost
help
Available commands:
(...)
| exit
| help [<command>]
| list
| quit
| request.alive
| request.all
| request.metadata <rid>
| request.on_air
| request.resolving
| request.trace <rid>
| uptime
| var.get <variable>
| var.list
| var.set <variable> = <value>
| version

Type "help <command>" for more information.
END
exit
Bye!
END
Connection to localhost closed.
%%

This is an example of how you can use an existing secure access to 
secure the access to liquidsoap's command server. This way, you make sure
that you are using a mainstream secure application, here SSH.

This example may be adapted similarly to use an online HTTP login 
mechanism, which is probably the most comment type of mechanism
intented for the command line server.

