Checking server permissions on a server¶
This section describes the procedure followed to check whether a user has permission to access a resource. The resource file is checked repeatedly until a suitable record is found. The order in which checks are made is important, because a right can be denied for a particular user but permitted for all others.
If the user is authenticated (UserId > 1) {
If a record exists for this resource and UserId, use this record’s access. The permissions are specific for the user and resource combination.
If a record exists for this resource and the UserId 1, use this record’s access. All authenticated users have these permissions for this resource.
If a record exists for this sub-resource in all categories (“*:sub_resource”) and UserId, use this record’s access.
If a record exists for this category (“category:*”) and UserId, use this record’s access.
If a record exists for all resources (“*:*”) and this UserId, use this record’s access.
}
If a record exists for this resource and the UserId 0, use this record’s access. All users have these permissions for this resource.
If the user is authenticated (UserId > 1) {
If a record exists with this sub-resource in all categories (“*:sub_resource”) and the UserId 1, use this record’s access. All authenticated users have these permissions for the sub-resource.
If a record exists for this category (“category:*”) and the UserId 1, use this record’s access. All authenticated users have these permissions for the category.
If a record exists for the resource “*:*” (general rights) and the UserId 1, use this record’s access. All authenticated users have these permissions for all resources.
}
If a record exists with this sub-resource in all categories (“*:sub_resource”) and the UserId 0, use this record’s access. All users have these permissions for the sub-resource.
If a record exists for all resources (“*:*”) and the UserId 0, use this record’s access. All users have these permissions for all resources.
If all these checks fail, access is denied.
Permissions are checked when a file is opened and before executing an application. The rights remain valid until the file is closed, even if another user is logged in by the same client. This makes it possible to access one set of files and then change the user to open another set. Only the last logged-in user is used to check permissions.
EXAMPLES
Give all authenticated users read and write access to the Sculptor keyed file “testfile”, except for the user “marcos”, whose UserId is 4.
Resource |
UserID |
Access |
“skf:testfile” |
1 |
SEC_ACCESS_READ | SEC_ACCESS_WRITE |
“skf:testfile” |
4 |
SEC_ACCESS_NONE |
Give all users read access, and “marcos” read and write access.
Resource |
UserID |
Access |
“skf:testfile” |
0 |
SEC_ACCESS_READ |
“skf:testfile” |
4 |
SEC_ACCESS_READ | SEC_ACCESS_WRITE |
Give all users read access to all resources.
Resource |
UserID |
Access |
“*:*” |
0 |
SEC_ACCESS_READ |
RELATED TOPICS |