The "AcuAccess" file contains a database of access records that determine which machines and which users are allowed to use AcuODBC. Depending on the construction of the database records, the server access file can provide many levels of system access, from very permissive to very restrictive. By default, system access is permissive, so before beginning AcuODBC Server operation, you should customize the file to a level of security appropriate for your application.
To modify the server access file, log onto the server as the superuser (UNIX) or Administrator (Windows) and type:
acuodbcs -access
The "acuodbcs -access" command starts the access file manager utility. When the access file manager starts, you are prompted for the path and name of the server access file. To accept the default value, simply press <return>.
After opening the access file, the manager displays a menu of five options:
Server Access File Options: 1. Add a security record 2. Remove a security record 3. Modify a security record 4. Display one/all security records 5. Exit
Use the access file manager to customize the AcuAccess file as required.
Access records may include wild cards that allow all clients or all users (except root under UNIX and Administrator under Windows NT or Windows 2000) access to AcuODBC Server. Or you can create individual access records for each user of each client. By having individual access records, you can restrict access to only those users specifically named in the access file.
The individual access records allow you to specify the user ID that AcuODBC Server will use when executing requests for users matching the given record. In this way you can assign a user ID that has exactly the privileges needed, and no more (typical of group access accounts).
In addition, every access record can include a password entry that the application or user must match before AcuODBC Server establishes a connection. (Whether this password is used on Windows NT/2000 servers depends on the value of the "NT Security" setting on the AcuODBC Server tab of the AcuODBC Configuration property sheet. See section 9.2, "Configuring the Remote DSN on the Client" for more information.
Creation and modification of the server access file requires root privileges on UNIX, and Administrator or Administrators group privileges on Windows NT or Windows 2000.
On UNIX servers the access file must be owned by root. The access file cannot be writable by anyone other than root. If the access file does not exist, is not owned by root, or is writable by users other than root, AcuODBC Server will not start.
On Windows NT and Windows 2000 servers, you should protect the access file by allowing only the Administrator or someone in the Administrators group to have write access to it. If the access file does not exist, is not owned by Administrator or the Administrators group, or is writable by users other than Administrator or the Administrators group, AcuODBC Server will not start.
Access record composition
The server access file contains one or more access records. Each access record is composed of five fields:
| Field | Function |
| Client Machine Name | The name of the client system. |
| Client Username | The user's login name on the client system. |
| Local Username | The local user name that AcuODBC Server will use when fulfilling requests for the client user. |
| Password | Optional password protection. When used, the requester must supply a password that matches this field. |
| Umask | A three-digit file creation mask. This field is not used by AcuODBC Server. However, since the AcuAccess file is used by several Acucorp products, this field is present. |
A typical server access record might look like:
Client Machine Name Client Username Local Username Password Umask starling bernie bsmith <none> 002
This record will allow user bernie to connect from machine starling. AcuODBC Server will use the local user name bsmith (Bernie's account on the file server) when executing requests for bernie. No password is required.
Three fields, Client Machine Name, Client Username, and Local Username, can have a wild card value to indicate a general behavior. These wild cards are:
| Field name | Wild card | Meaning |
| Client Machine Name | * | Match all clients machines |
| Client Username | (empty field) | Match all client users |
| Local Username | same as client | Use the Client Username |
For illustrative purposes, here is a set of common access records:
Client Machine Name Client Username Local Username Password Umask support-pc techie <none> 002 warehouse-pc <none> 002 president-pc diamond <same as client> <none> 002 robin <same as client> <none> 002 starling felice <same as client> <none> 002 starling baxter ...... 002 swallow hartley hartley <none> 002 swallow acct <none> 002
These entries are interpreted as follows:
The entry for support-pc allows any user of support-pc to use AcuODBC Server. AcuODBC Server will use the local user name techie when executing requests for support-pc.
The entry for warehouse-pc allows any user of warehouse-pc to use AcuODBC Server.
The entry for president-pc allows user diamond to access AcuODBC Server. For this record to match, the DOS environment variable USERNAME or USER must be defined with the value "diamond". AcuODBC Server will also attempt to use diamond as the Local Username.
The entry for robin allows all users of robin to access AcuODBC Server. If the requester has an account on the server by the same name, AcuODBC Server will use that name.
The first entry for starling allows user felice to access AcuODBC Server. AcuODBC Server will follow the same rules as the previous entry to assign a local user name.
The second entry for starling allows user baxter to access AcuODBC Server. baxter will need to provide a password before a connection will be established.
The first entry for swallow allows user hartley to access AcuODBC Server. AcuODBC Server will use the local user name hartley when executing requests for hartley.
The second entry for swallow allows all users of swallow to access AcuODBC Server. AcuODBC Server will use the local user name acct for all users of swallow, except hartley (or other records for swallow that explicitly name a client user).
The most permissive access record that can be created is:
Client Machine Name Client Username Local Username Password Umask * <same as client> <none> 002
This record allows any user of any client to use AcuODBC Server, so long as they have an account on the server by the same name.
More: