How the System Determines If a User Can Access a Protected Object

If both a Table of Contents and Search form are not displayed in separate frames along with this one, you may wish to redisplay this book in a frameset, beginning with the first page.

HP OpenVMS Guide to System Security

Security for the User

Protecting Data

Security Profile of Objects

Controlling Access with ACLs

How the System DeterminesIf a User Can Access a Protected Object

When a user tries to access a protected object, the operatingsystem calls the Check Protection ($CHKPRO) system service to comparethe security profile of the user process with the security profileof the object. In the protection check, $CHKPRO compares the user'ssecurity profile against the protected object's profile using thefollowing sequence:

Evaluate theaccess control list (ACL).

If the object has an ACL, the system scans it, looking foran entry that matches any of the user's rights identifiers. If amatching access control entry (ACE) is found, the system eithergrants or denies access, and further checking of the ACL stops.

When the matching ACE denies access, a user can still gainaccess either through the system and owner fields of the protectioncode or through privilege. When an ACL has no matching ACE, thesystem checks all fields of the protection code.

Evaluate the protection code.

If the ACL did not grant access and the object's owner UICis not zero,¹ theoperating system evaluates the protection code. Theoperating system grants or denies access based on the relationshipbetween the user's identification code (UIC) and the object's protectioncode.

For cases where an ACL has denied access, the system examinestwo fields in the protection code---the system and owner fields---todetermine if the user is allowed access. The user can still acquireaccess by being a member of the system or owner categories or bypossessing privileges. A user holding GRPPRV (with a matching groupUIC) or SYSPRV is granted the access specified for the system categoryof the protection code.

Look for special privileges.

If access was not granted by the ACL or the protection code,privileges are evaluated.

Users with certain system privileges may be entitled to accessregardless of the protection offered by the ACLs or the protectioncode. The bypass privilege (BYPASS), group privilege(GRPPRV), read all privilege (READALL), or system privilege (SYSPRV) amplifies the holder'saccess to objects. (See How Privileges Affect Protection Mechanisms for more information on how privileges affect access.)

Consider access overrides.

For some object classes, access may be granted based on alternateprivileges. For example, the queue object allows full access toall queues for users with operator privilege (OPER), and the logicalname table object allows access to the system table for users withsystem name privilege (SYSNAM).

Flowchart of Access Request Evaluation chartsthe sequence the operating system follows when it evaluates an accessrequest and shows how the controlling components (ACLs, protectioncodes, privileges, and access overrides) interact.

Figure 3 Flowchart of Access Request Evaluation
tbs

Figure 4 Flowchartof Access Request Evaluation (cont'd)
tbs

Figure 5 Flowchartof Access Request Evaluation (cont'd)
tbs

Figure 6 Flowchartof Access Request Evaluation (cont'd)
tbs

Figure 7 Flowchartof Access Request Evaluation (cont'd)
tbs

Footnotes

1
When an object has an ownerUIC of zero, the protection code is not checked. Users have allbut control access to the object, provided theACL has no Identifier ACEs. If Identifier ACEs are present, thenaccess has to be granted explicitly through the ACL or through privilege.

( Number takes you back )

Security Profile of Objects

Controlling Access with ACLs