Security and Data Protection in Zim Applications

Permissions

A permission mask is assigned to all application directories, to all EntitySets and relationships, and to all fields in EntitySets and relationships. The permission mask indicates the type of access that particular user IDs are to have to the object.

The possible permissions for EntitySets and for relationships are READ, ADD, CHANGE, and DELETE. ADD, CHANGE, and DELETE automatically enable you to READ the data.

The possible permissions for directories and for fields are READ and UPDATE. UPDATE automatically enables you to READ the data.

Ownership

The creator of each directory, EntitySet, or relationship is the owner of that object and of the fields in it. The owner of the Object Dictionary EntitySets, created when the new application database is initialized, is any user whose UserID is 0.

Owners can set and change the permission mask for the objects they own. Individual permission masks can be set for

the owner

Owner includes any user whose $ZUserID matches that of the object owner.

the group

Group includes any user whose $ZGroupID matches that of the object owner.

all others

Others includes all users that do not share the $ZUserID or $ZGroupID of the object owner.

For example, the owner of an EntitySet can grant permission for all users in his or her group to ADD data to an EntitySet, but might restrict other users (not part of the group) to READ only. In addition, the owner can restrict access to certain fields in the EntitySet: for example, by assigning READ access for users in the group and no access for other users.

Permission Checking

Each time that a user tries to access the data in a directory, an entity set, a relationship, or a particular field, the permission mask that is in force for the object is checked against the system variables $ZUserID and $ZGroupID.

First $ZUserID is checked to see if the user is the owner of the object. If the user is the owner, the object's owner permission mask is used to determine if the user can perform the requested operation. If the user is not the owner but is in the owner's group, the object's group permission mask is used to determine if the user can perform the requested operation. Otherwise, the object's others permission mask is used to determine the user's access.

Effects on Commands

The applicable permission mask has an effect on command execution. You must have READ or UPDATE permission to access an application directory. You must have UPDATE permission to CREATE, ERASE, or RENAME objects in an application directory.

For example, if you enter

access EmployData update
change NewEmps1 from Employees
add NewEmps2 from Employees
create index NewEmps2.FirstName

you must have at least READ permission in order to access the directory EmployData. To make changes to the definitions of the objects in that directory, you need UPDATE permission.

You must have READ permission for the two commands involving the Employees EntitySet. In addition, you must have CHANGE permission for NewEmps2 and ADD permission for NewEmps2. You must also have READ permission for any fields in Employees that you are using, and UPDATE permission for the fields in NewEmps1 and NewEmps2 whose values you are adding to or changing.

When you create an index for NewEmps2.FirstName, you must have UPDATE permission for the directory EmployData (assuming that NewEmps2 is defined in that directory).

If you enter

delete all Employees where LName = Smith

you must have DELETE permission for Employees.

If you lack a required permission at the directory, EntitySet, or relationship level, the command does not execute; an error message is issued. If, at the field level, you attempt to read data from a field for which you do not have READ permission, the result you obtain is $Null; if you attempt to assign a value to a field for which you do not have update permission, the assignment is not made. No error messages are issued.

Changing Default or Established Permissions

When an object (other than a directory) is created, it has all possible permission for the owner, READ permission for the owner's group, and no permission for all others. By default, newly created directories give READ and UPDATE permission to all users.

To change the permission masks, the owner (or the super user) uses the PERMISSION command. The permissions mentioned in the PERMISSION command are always added to the existing permission mask for that object.

In the following example

permission Employees other read add
permission WorkOn group read add change delete
permission Projects other
permission LName group update
permission Salary group other
permission ENum owner read

Employees and Projects are EntitySets, WorkOn is a relationship, and LName, Salary, and ENum are fields. Note that you can leave permissions blank; the affected users cannot access the objects at all.

Object permissions

There are two types of permissions - object permissions (EntitySets, relationships, and directories) and field-level permissions. Field level permissions take precedence over object permissions. The permissions are set as follows:

The following chart summarizes the permissions needed in order to successfully execute a given form of data manipulation on an object where permissions are currently in place. Definitions are as follows:

Note: Any user with a GroupID equal to 0 is considered to be a superuser. Superusers are not governed by permissions currently in place on objects, fields, or both. Thus, an object is created by a person logged in as superuser, then permissions applied to the Group are ignored since every user in the creator's group is a super user. It is not advisable to create objects while logged in as a superuser, in order to take full advantage of Zim's security features. Different permissions can be assigned to objects, fields, or both for users inside the owner's group (Group) and to users outside the objects' owner group (Other).

Who

EntitySet permission

Field permission

List

Change

Add

Delete

owner

R***

**

no

no

no

no

owner

R***

R*

yes

no

no

no

owner

R***

RU

yes

no

no

no

group

R***

**

no

no

no

no

group

R***

R*

yes

no

no

no

group

R***

RU

yes

no

no

no

other

R***

**

no

no

no

no

other

R***

R*

yes

no

no

no

other

R***

RU

yes

no

no

no

owner

RA**

**

no

no

null(1)

no

owner

RA**

R*

yes

no

null(1)

no

owner

RA**

RU

yes

no

yes

no

group

RA**

**

no

no

null(1)

no

group

RA**

R*

yes

no

null(1)

no

group

RA**

RU

yes

no

yes

no

other

RA**

**

no

no

null(1)

no

other

RA**

R*

yes

no

null(1)

no

other

RA**

RU

yes

no

yes

no

owner

RAC*

**

no

no

null(1)

no

owner

RAC*

R*

yes

no

</ td>

null(1)

no

owner

RAC*

RU

yes

yes

yes

no

group

RAC*

**

no

no

null(1)

no

group

RAC*

R*

yes

no

null(1)

no

group

RAC*

RU

yes

yes

yes

no

other

RAC*

**

no

no

null(1)

no

other

RAC*

R*

yes

no

null(1)

no

other

RAC*

RU

yes

yes

yes

no

owner

RACD

**

no

no

null(1)

yes

owner

RACD

R*

yes

no

null(1)

yes

owner

RACD

RU

Yes

yes

null(1)

yes

group

RACD

**

no

no

null(1)

yes

group

RACD

R*

yes

no

null(1)

yes

group

RACD

RU

yes

yes

yes

yes

other

RACD

**

no

no

null(1)

yes

other

RACD

R*

yes

no

null(1)

yes

other

RACD

RU

yes

yes

yes

yes

where R = read, A = Add, C = Change, and D = Delete

(1) Null values for all fields with no update permission