SECURITY

Many people have access to a database: managers, analysts, data-entry clerks, programmers, temporary workers, and so on. Each individual or group needs different access to the data in the database. For example, the Finance Director needs access to salary data, while the receptionist needs access only to names and departments. R&D needs access to the library's research reports, while Legal needs access to depositions in pertinent court cases.

Texis maintains permissions which work in conjunction with the operating system security. Texis will not change the operating system permissions on a table, but it will change the permissions on the indices to match those on the table.

This scheme allows the operating system to give a broad class of security, while Texis maintains finer detail. The reason for the combination is that Texis can not control what the user does with the operating system, and the operating system does not have the detailed permissions required for a database.

When a table is created it initially has full permissions for the creator, and read/write operating system permissions for the creator only.

When using Texis permissions the operating system can still deny access which Texis believes is proper. To prevent this from happening Texis should always be run as one user id, which owns the database. The easiest way of doing this on Unix is to set the suid bit on all the programs that form the Texis package, as well as any user programs written with the direct library, and change the user to a common user, for example texis. Alternative methods may exist for other operating systems.

• Creating Users and Logging In
• Granting Privileges
  • Command Discussion
• Removing Privileges
  • Command Discussion