CHAPTER 7 ■ CONTROL HUBS 228 This uses the tweet command to update their Twitter status, thereby using the configuration information from the given user, with their credentials being stored in $MINBASE/etc/users/[user]/external/twitter. The Voice Conduit Input/output. In its current state, all voice recognition input is taken from an HTTP request on a separate page that triggers the msgrcv script with the given command. The output conduit has a direct connection to the Festival speech synthesis suite, which has already been abstracted through Bearskin with say and announce. Vocal output is also a very good debugging conduit, since the output is immediately accessible. Web Log Output only. This is the same as the standard logger but writes its output to a different file, /var/log/minerva/weblog. Window Alert Output only. This displays the message on an X Window terminal using the basic kdialog program. The existing script exports the DISPLAY variable to display the box on the current system but could be set to any suitably configured installation of X Window on the network. If you need this to support Windows users, then you must install some software (such as Apache) onto those machines to listen for an incoming message and then use it to trigger a small script once the appropriate message is received. The following code, called message.js, will use the Windows Scripting Host (WSH) to display a suitable box: message = ""; for (i = 0; i < WScript.Arguments.length; i++) { message += WScript.Arguments.Item(i) + " "; } Wscript.Echo(message); Note that the file extension is important, since this is used to determine the particular scripting engine. Administering Conduits The administration of conduits is simple, since the major work is handled by the commands themselves. The task of adding conduits to the system is processed by the msgconduit command. This command can either list the existing conduits, shown earlier, or add a new one, like so: msgconduit create newconduitname CHAPTER 7 ■ CONTROL HUBS 229 or add a new command into an existing conduit: msgconduit add conduitname conduitcommand original command with arguments ■ Note There is also an msginstall command, which is executed automatically during the installation process. Its sole purpose is to create the existing conduits, listed earlier. You should never need to call this. Messaging Conduits Having now gotten some conduits to send and process messages, you need to abstract them one stage further so they can be controlled from a single script. This is because each conduit has a lot of common functionality, such as address book lookups, which can be unified into a single place. You therefore create two commands: msgxmit, which sends messages into the output conduits, and msgrcv, which is called by the various daemons when an input conduit receives a message. Output Conduits: Transmission These are based solely around the msgxmit script, which is a method by which messages are sent to one or more (comma-separated) users by one or more (also comma-separated) conduit protocols. This allows you to use this master script to separate the target addresses, as well as perform address book lookups, so that each conduit driver script needs to accept only a single destination address. Like all commands, you need a standardized format. This one will be in the form of conduit, address, and message: msgxmit sms myphonenumber "An SMS from the command line, but could be anywhere" This avoids the complication of a subject line, priority levels, attachments, and embedded links. They could be added but would only make logical sense in specific transport conduits. Consequently, you do not try to process them (or remove them with preprocessing) and instead pass the message through directly to the appropriate driver script. The conduit may, at its discretion, elect to choose a subject line based on the message if it desires. For example, the SMS transmission in the previous example would determine that the SMS conduit was to be used and call the specific driver function like this: mxsms sms 012345678 "An SMS from the command line, but could be anywhere" The naming convention follows that the transmission script is always called mx, followed by the conduit name. In some cases, two abstractions are involved. Speech output, for example, occurs with the vox conduit: msgxmit vox default "I am talking to everyone in the house" CHAPTER 7 ■ CONTROL HUBS 230 This trickles down into the mxvox script, which in turn will call say: mxvox vox default "I am talking to everyone in the house" The conduit type is included as an argument at each stage as a sanity check and to allow one underlying command to be used by more than one conduit. So that new conduits can be added without changing the msgxmit script, you create a directory structure that details each of them. For example, the folder will detail the SMS account credentials, address book aliases, and the all-important command that transmits the message as I covered earlier: /usr/local/minerva/etc/msg/sms So, given a conduit type (or comma-separated list of several conduits) in the argument $1 and a list of addresses similarly separated in $2, you can process them with the following: SAVEIFS=$IFS IFS="," declare -a CONDUIT_ARRAY=($1) shift declare -a TO_ARRAY=($1) shift IFS=$SAVEIFS MSG=$* and then enumerate each conduit with the following: for CONDUIT in ${CONDUIT_ARRAY[@]} do CMD=$MINBASE/etc/msg/$CONDUIT/xmit/cmd if [ -f $CMD ]; then # existing conduit – send the message to each user fi done Knowing the conduit, you can consult the conduit-specific address book in $MINBASE/etc/msg/[conduit_name] to replace the username with a number. You use a space-separated list as follows: steev 012345678 teddy 012347890 As mentioned previously, this results in the SMS-specific script dealing only with the canonical form of phone number and limits the complexity in each of the protocol scripts. Obviously, if the address is already in its canonical form, then it won’t appear on the left side of the list, and you can revert to the original input. When sending information, you also check a second list of addresses that consists of non- Minerva users and can be used to store your work numbers. This code appears thus as follows: CHAPTER 7 ■ CONTROL HUBS 231 ADDRBOOK=$MINBASE/etc/msg/$CONDUIT/addr/alias if [ -f $ADDRBOOK ]; then ALIAS=`grep -m 1 "^$TOADDR " $ADDRBOOK | sed "s/^[^ ]* //"` if [ "$ALIAS" != "" ]; then TOADDR=$ALIAS fi fi It is then a simple case of calling the driver script and optionally logging the message details to a file: $CMD $CONDUIT $TOADDR $MSG Input Conduits: Receiving Messages This uses the same set of abstraction principles as transmission but in reverse. Minerva has a basic script, called msgrcv, which processes any commands found in the message, regardless of where the message originated. This script then checks to see whether the sender is allowed to issue that command and refuse it if not. ■ Note This process is the most obvious example of the insecurity present with the system, since any Linux user is able to call the script with valid parameters and bypass your security. Even if you made all the files read-only, it is no effort for someone to copy or retype these locally and execute the commands. This is yet another reason why local users are all but banned from the server. There are various complications with receiving and processing messages, since every type of communication is different, both in how the text format is used and the way in which messages are picked up the system. In Chapter 5 you saw examples of how e-mail and SMS require significantly different code to process the incoming message. My approach is to let the software that receives the communication in the very first instance (the web or e-mail server, for example) to authenticate the user. Most of these daemons will be running as a privileged user of some description and therefore less vulnerable to abuse. In addition to deducing the Minerva-oriented user account of the sender, the receiving code will also be in charge of stripping out all message information that is not pertinent (in the form of header, footers, signatures, and so on) before sending a much-reduced command to your msgrcv script. This pushes the workload to where it belongs and gives your script a unified appearance to all input conduits. Taking the example of SMS, you already have a web page in place that is invoked whenever someone sends a message to your house. This page might process the input and call the receiver script using the following: CHAPTER 7 ■ CONTROL HUBS 232 $command = "/usr/local/minerva/bin/msgrcv sms "; $command.= $_POST['from']; $command.= " "; $command.= $_POST['text']; system($command); which evaluates down to a command such as the following: msgrcv sms 012345678 bedroom on The command code can then look up the phone number in $MINBASE/etc/msg/sms/addr/alias and deduce who is issuing the command and whether they’re allowed to use it. From here you can determine how to process the command and its arguments in a uniform way. However, allowing arbitrary access to the entire Linux command set is very dangerous, particularly given the privileges under which software such as the web server is run. As you’ve just seen, even the seemingly inconspicuous SMS control requires Apache and is therefore vulnerable. Therefore, each user has a list of applications it is allowed to use, as controlled with the minuser command. Furthermore, you can kill two proverbial birds with one stone by preparing your own set of aliases. Some commands, like kettle, are short and simple and effective for SMS messages. Others such as the following are not: x10control default on bedroom_light Consequently, you will create a directory /usr/local/minerva/etc/msg/sms/cmd that contains a number of command scripts with short names. bedroom, for example, would perform the full command given earlier. You could also create an aliased command called sleepover, which runs the following: x10control default off bedroom_light x10control default off studio_light x10control default off lounge_light This would eliminate a lot of typing and limit the scope for command injection attacks. This also allows you to add new SMS-controllable commands without changing the SMS input handler code inside the web directory. Notice that in this example and all others like it, you always pass the conduit type and address through to the underlying script as you did with msgxmit. You suffer no performance penalty for doing so, and it ensures that error reports are sent back to the correct user, using the same conduit. One powerful example of this is with voice control. In Chapter 5 you used Apache to trigger individual scripts when a specific web page was accessed. With this input conduit abstraction, you can extend the scope of your voice input very simply. Like SMS, you create a simple web page that picks up each request and invokes msgrcv. You have created voxcontrol.php that reads as follows: <?php $cmd = $HTTP_GET_VARS['cmd']; $auth = $HTTP_GET_VARS['auth']; if ($auth == "") { $auth = "public"; } . the insecurity present with the system, since any Linux user is able to call the script with valid parameters and bypass your security. Even if you made all the files read-only, it is no effort. the conduit, you can consult the conduit-specific address book in $MINBASE/etc/msg/[conduit_name] to replace the username with a number. You use a space-separated list as follows: steev 012345678. similarly separated in $2, you can process them with the following: SAVEIFS=$IFS IFS="," declare -a CONDUIT_ARRAY=($1) shift declare -a TO_ARRAY=($1) shift IFS=$SAVEIFS MSG=$*