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 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.
You need to understand Unix userids/groups and file permissions for this section.
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:
> ls -l aceserver
-rwxrwx--- 1 elegans admingroup 1677668 Jan 18 20:31 aceserver
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.
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.
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.
drwxr-x--- 4 elegans mywrite 8192 Jan 18 20:32 write
drwxr-x--- 4 elegans myread 8192 Jan 18 20:32 read
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.