FairCom DB V12 Release Notes

FairCom Server file permission inheritance changes

We have cleaned up server file permission inheritance. Before this, setting permissions on files and then retrieving them could show permissions that were not explicitly set in the file permission mask. Taking into account c-tree's file permission inheritance hierarchy, the results could be unexpected in some cases. Here are some examples using the sa_admin utility to set file permissions:

Example #1:

Set permission:

OPF_WRITE GPF_DELETE WPF_READ

sa_admin -aADMIN -pADMIN -f"" -sFAIRCOMS -ofs mark.dat "-+------+-+----"

Resulting permission:

OPF_READ OPF_WRITE OPF_DELETE GPF_READ GPF_DELETE WPF_READ

Expected effective permission:

OPF_READ OPF_WRITE GPF_READ GPF_DELETE WPF_READ

(owner should not inherit DELETE from group)

Example #2:

Set permission:

OPF_WRITE WPF_READ

sa_admin -aADMIN -pADMIN -f"" -sFAIRCOMS -ofs mark.dat "-+--------+----"

Resulting permission:

OPF_WRITE WPF_READ

Expected effective permission:

OPF_READ OPF_WRITE GPF_READ WPF_READ

(owner and group should inherit READ from world even if owner or group have no other permissions)

Example #3:

Set permission:

OPF_READ GPF_DELETE WPF_WRITE

sa_admin -aADMIN -pADMIN -f"" -sFAIRCOMS -ofs mark.dat "+-------+--+---"

Resulting permission:

OPF_READ OPF_DELETE GPF_DELETE WPF_WRITE

Expected effective permission:

OPF_READ OPF_WRITE GPF_WRITE GPF_DELETE WPF_WRITE

(owner should not inherit DELETE from group; owner and group should inherit WRITE from world)

Causes

The following reasons explain this behavior:

1. The group inherits the world permissions and the owner inherits the group permissions.
2. When setting permissions on a file, the inherited permissions are applied to the permission mask that is stored in the file rather than being applied when reading the permissions from the file based on the permission inheritance hierarchy.
3. An improper bitmask macro definition caused the world WRITE permission to not be inherited by group or owner.
4. If group has the GPF_NONE permission specified, no inheritance of permissions from world to group occurs. If owner has the OPF_NONE permission specified, no inheritance of permissions from group to owner occurs. The sa_admin and ctadmn utilities turn on the GPF_NONE or OPF_NONE bit if no other group or owner permission is specified, which explains why in example #2 the world READ permission is not inherited by group or owner.

Changes

To improve the file permission inheritance behavior, the following changes have been made:

1. Permission inheritance is now calculated when reading the permissions from the file, so the permissions as originally specified are written to the file.
2. Inheritance occurs from world to group and from world to owner. Inheritance from group to owner no longer occurs, as this has been determined to be inappropriate.
3. Inheritance to group and owner occurs even if the GPF_NONE or OPF_NONE permission is specified.
4. The bitmask was corrected so that world WRITE permission is properly inherited by group and owner.

Note: If a file had a permission improperly inherited from group to owner, as in examples #1 and #3 above, this modification does not change that permission, because that permission value is stored in the file. However, for a file having permissions that were not inherited but should have been, as in example #2, the code modifications correct this situation by evaluating the permission inheritance when opening the file.

Compatibility Notes:

Behavior Change: This change modifies c-tree Server's inheritance of file permissions. As a result, behavior of file permissions differs from its previous behavior in the following ways, where "old server" means c-tree Server with original file permission behavior and "new server" means c-tree Server with the modified file permission behavior:

• The old server modified the file permissions based on the permission inheritance rules before storing the permissions in the file, so retrieving the permissions showed the inherited permissions. The new server stores the file permissions as originally specified by the administrator and calculates the permission inheritance when opening the file.
• When a new server opens a file whose permission was set by an old server, the only potential change in effective permissions is that additional permissions might be inherited from world to group and world to owner that were not inherited by the old server.
• When the new server sets permissions on a file, reading the permissions will return the exact same permissions that were set, and inheritance of permissions from group to owner does not occur.

Here are some specific cases to demonstrate this behavior:

Case #1:

Old Behavior: For a file that has world permissions assigned and no group permissions assigned, group and owner did not inherit any permissions.

New Behavior: For a file that has world permissions assigned (regardless of group permission assignment), group inherits world permissions, and owner inherits world permissions.

In this case, group and owner are granted additional permissions (the world permissions) compared to the old behavior.

Case #2:

Old Behavior: For a file that has world permissions assigned and at least one group permission assigned, group inherited world permissions, and owner inherited world and group permissions.

New Behavior: For a file that has world permissions assigned (regardless of group permission assignment), group inherits world permissions, and owner inherits world permissions.

In this case, owner is granted fewer permissions (because it does not inherit the group permissions) compared to the old behavior. However, a file that had its permissions set by an older server already had its group permissions inherited by owner when the permissions were stored in the file, and so those permissions inherited from group to owner remain for that file unless an administrator changes the file permissions.

Case #3:

Old Behavior: Due to a bug, group and owner never inherited world write permission.

New Behavior: Group and owner inherit world write permission.

In this case, group and owner are granted additional permissions (the world write permission that should have been granted) compared to the old behavior.

Compatibility Change: Due to these modifications in permission inheritance behavior, the INHERIT_FILE_PERMISSIONS server configuration option is no longer supported.