Aside from the privilege considerations discussed above, there are a couple of more advanced settings that you will need to consider, and if desired, carry out manually in order to enable certain auxiliary utility operations such as CHAT, SEND, KILL, and LOKUTL. The basic problem is that unlike AMOS, where assembly language commands or subroutines can read from and write to any region of memory, including the monitor and other jobs’ partitions and control blocks, under Unix it is generally not possible for one job to see or affect any other job’s private information, nor is it possible to see the kernel’s private memory. There are two general cases to consider here.
The first is the case of a utility that needs to see or affect another job, such as KILL, SEND, or CHAT. To allow this, the sender and receiver must either both be running under the control of the same effective user, or the sender must have root (superuser) privileges. The second case occurs when we need to access kernel information (such as the lock list, or the list of active processes.) In that case, we must have superuser privileges. Since having every user log in as the same user, and especially as the superuser, would defeat all of the safeguards which help make Unix a more reliable operating system than AMOS or Windows, we need a way to temporarily obtain the necessary privileges in a way that is out of the control of individual users to abuse. The SETUID mechanism allows us to do this, by providing a special bit in the directory entry for an executable command which causes the user of that command to assume the privileges of the owner (creator) of the command, but only while executing the command. As an example, the Unix utility ps (process status) uses this technique to allow anyone with sufficient privileges to execute ps to temporarily acquire the superuser privileges necessary to read the kernel’s process table in order to display a list of what every process is doing.
The A-Shell utilities KILL.LIT, SEND.LIT, and CHAT.LIT fall into the first category of commands described above, since they require that both the sender and receiver either share the same effective user ID, or that the sender be the superuser. Of the two alternatives, we prefer the former, since as a general principal it is wise to limit the use of superuser privileges to the bare minimum. So instead, we can use the SETUID bit to cause everyone that is running under ashell to have effectively the same user privileges. For example:
# cd /vm/miame/bin
# chown ashusr ashell
# chmod +s ashell
The above commands, we first make the user ashusr be the owner of the ashell executable, and then we use the chmod +s command to turn on the SETUID bit. Thus all users executing ashell will assume the effective identity ashusr while they are in A-Shell, and thus then can use SEND, CHAT, and KILL on each other. (You must first create a user called ashusr.) Note that this "effective" user ID does not conflict with the login ID, which remains distinct, and which is used in utilities such as SYSTAT to allow you to distinguish the users from each other.
Because of the dangerous implications of the KILL command, there is another level of safety involved in enabling its use which is described in section following titled "Enabling the Use of KILL."
The second case of utilities (those that need superuser privileges to access kernel information) are mostly taken care of by the standard operating system installation, and are not of particular to concert to A-Shell. There are a couple of exceptions though, most notably the lslk (list locks) utility, which is used by A-Shell’s LOKUTL.LIT (under Unix versions) to access the list of locked files and records. Since this utility comes from a shareware source you may need to manually install it (either in the same directory as the ashell executable or somewhere in the PATH) and, if not already done, change the owner to root and set the SETUID bit using chmod +s as shown below:
# cd /vm/miame/bin
# chown root lslk
# chmod +s lslk
In most cases, lslk is distributed with and installed by A-Shell, but you may still need to perform the above steps since the ownership and privileges may get overwritten by the steps described in File Ownership and Privileges above.
Another utility similar to lslk which may be distributed with A-Shell (or obtained from the web) is lsof, which displays a list of open file handles by user. You would also want to set the ownership and privileges for it exactly as for lslk, even though it is not integral to A-Shell.
