Appendix A

(Acedb 4.7 RPC version)

This appendix shows in more detail how to control client/server access to a database.

Unfortunately controlling access to files/programs on computer systems is not straight forward, it usually consists of the interaction of several different components/facilities that must all be set correctly to achieve the desired level of security. In our case we will need to consider the following:

the file permissions of the server program itself (and perhaps those of the client program)
the file permissions of the database directories and files
the acedb server control files

The first two items are about providing basic UNIX protection, the last item is about providing control via the servers access mechanisms. We will consider these two separately.

In addition, if clients and servers are to be run on different machines (which is usually the case), all machines will have to run remote file handling software such as NFS. This is necessary to make the servers read/write control files available to the client. It is important that the server machines do not allow root users from other machines to mount the database directory with root permissions otherwise they will be able to change all the database permissions.

File permissions:

You need to understand Unix userids/groups and file permissions for this section.

server/client program permissions

We can use Unix permissions to limit who can run the server and client programs. This is an important first line of defence in setting up a database securely.

Usually it is sensible to limit who can run the server to a few administrators or even to a single special administrator id. For instance, assuming that we have a special administrator id called elegans who should be able to run the server, but that we also want a group of chosen userids (e.g. fred and michele) to be able to run the server program for testing then we need to do the following:

ask systems admin to create a group e.g. "admingroup" and put "elegans", "fred" and "michele" in that group

as the elegans user, set the file permissions for the server so they look like this:


       > ls -l aceserver
       -rwxrwx---   1 elegans   admingroup      1677668 Jan 18 20:31 aceserver

This means that only elegans and users in the admingroup will be able to run the aceserver and replace it with a new version or look at it with an editor (the latter is unlikely because the file is compiled code).

The client could be similarly limited to a few users but this can be more trouble than its worth because the group for the client program file would have to be constantly changed as users came and went. A more flexible approach is to provide general access to the client to run it (but not look at it with an editor or replace it):


> ls -l aceclient
-rwxrwx--x   1 elegans   admingroup      301600 Jan 18 20:32 aceclient

The means that elegans and admingroup users will be able to run, replace and look at the client, anybody else can run the client. In the next section we will see how, even though anyone can run the client, we can control who actually gets access to the database via the servers access control mechanism.

database file permissions

Finally in this section we must set the file permissions of the database itself. Its not much good setting the permissions of the server program but leaving the database files so that anyone can alter them manually !

Given the preceding permissions/groups it is sensible to set the file permissions of the database to the same as the server program. This will allow the server program to access the database and also the elegans userid and admingroup userids. The files/directories of the database should be set so that they give read, write and execute permission to elegans and admingroup and nothing to anyone else:


> ls -l YOURDB

drwxrwx---   5 elegans   admingroup        1024 Apr 21  1999 database/
drwxrwx---   3 elegans   admingroup        3072 Nov  4  1998 whelp/
drwxrwx---   2 elegans   admingroup        1024 Jan 26  1999 wspec/

               etc. etc.

The easiest way to do this is to "cd" to the parent directory of the database and then use "chown", "chgrp" & "chmod" commands with the "-R" flag to change the ownership and permissions of the of the database directory itself and all its sub-directories and files:


> cd 
> chown -R elegans ./YOURDB
> chgrp -R admingroup ./YOURDB
> chmod -R ug+rwx ./YOURDB
> chmod -R o-rwx ./YOURDB

We now have the server and client program permissions set up and the database permissions set, now we need to set up the servers access control system.

Server Access Control:

The server access control mechanism is unusual because it uses Unix file permissions instead of passwords to control access. The way that this works is as follows:

Users wishing to access the database must be able to read files in a special directory that is controlled by the server. The files contain a magic number that the client must return to the server before it can gain access to the database. There is a directory for read access and another for write access. Hence the correct way to set these directories up is so that the server owns and can write to them and that all users that should be given access to the database can read them. The directory must be set up so that it can mounted by other machines on the network using shared file system software such as NFS.

The server can provide varying levels of access to the database:

				read access
			no one		group		anyone

	no one		not allowed	OK		OK

write	group		OK		OK		OK
access
	anyone		OK		OK		not allowed

The only two combinations disallowed are that no one has read/write access or that everyone has read/write access, the former renders the database inaccessible, the latter is just not a good idea !!

Two files are used by the server to control access to the database:


    YOURDB/wspec/passwd.wrm
    YOURDB/wspec/server.wrm

We'll take these separately as they are used differently by the server.

YOURDB/wspec/passwd.wrm You should already know that in order to get write access to the database your userid must be in this file, this applies whether you are using xace, tace or any other acedb program. The same is true for the server, but which userid should be in passwd.wrm ? If you run the server in the foreground as in the examples above then the server will be running as though it were you, so your userid must be in passwd.wrm. But what if the server is started up automatically by the operating system ? In this case the userid should be the one that "owns" the server program. To find out who this is use the "ls -l" command:


> ls -l aceserver
-rwxr-xr-x   1 joebloggs   theworld    2334720 Jan 18 09:16 aceserver

In this case "joebloggs" is the owner of the aceserver file/program so "joebloggs" should be put in the file passwd.wrm. Note that if you forget, you cannot do this while the server is running, you must stop and restart it.

So passwd.wrm should contain the userids of anyone who is allowed to start the server AND the owner of the server program file. These entries allow the server program itself to get access to the database, the next section shows how to give clients access.

YOURDB/wspec/server.wrm The file server.wrm contains keywords (WRITE_ACCESS_DIRECTORY & READ_ACCESS_DIRECTORY) that control read and write access to the database. These keywords are followed by the names of directories into which the server will place files containing special numbers that the client must read and return in order to get the required access level. The directory permissions are set up to restrict which users can read which files.

The upshot of this is that if you have permission to read files in the WRITE_ACCESS_DIRECTORY then your client program will be able to read the servers write permission number and you will get write access. If this is not possible the client will try to read a file in the READ_ACCESS_DIRECTORY, if this fails then you will not get access to the database.

A common requirement is that restricted users are given write access but anyone is given read access, if you put the word "PUBLIC" after READ_ACCESS_DIRECTORY then anyone will have read access.

It's also possible to make the database "read only", to do this you just need to comment out the WRITE_ACCESS_DIRECTORY line by putting a "//" at the beginning of the line.

Some care is required in setting this up, lets assume that as before the server program is owned by "elegans" and that "fred" and "michele" are to be given write access while "Ele" and "Joe" are to be given read access.

Create a Unix group for users who are to have write access, e.g. "mywrite", and put fred and michele in this group.
Similarly create a Unix group for users who are to have read access, e.g. "myread", and put Ele and Joe in this group.
Make two directories owned by the same userid as the server program, one will be the "write", the other the "read" direcotory. They should have these permissions:
```
       drwxr-x---   4 elegans   mywrite           8192 Jan 18 20:32 write
       drwxr-x---   4 elegans   myread            8192 Jan 18 20:32 read
       
```

Now the server can write to either directory, fred and michele can read the "write" and Ele and Joe can read the "read". Hence fred and michele will be able to get write access and Ele and Joe will be able to get read access. The following table summarises how you should set up YOURDB/wspec/server.wrm to get the various combinations of read and write access:


   Access            
   required          WRITE_ACCESS_DIRECTORY        READ_ACCESS_DIRECTORY

    no one              comment out                   comment out 

    group              set to write directory       set to read directory

    anyone              NOT POSSIBLE                set to "PUBLIC"

Not all combinations are legal, you should see the table earlier in this appendix for legal combinations.

You should now be able to control access to the database with just about any degree of control you want. The only limiting factor with this mechanism is that both client and server must be able to access the directory where the access files are kept. A major advantage of the mechanism is that users do not have to remember another password.