InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Extending the Output Values of Storage ACLs to Control Restricted Access

IP.com Disclosure Number: IPCOM000234924D
Publication Date: 2014-Feb-16
Document File: 3 page(s) / 32K

Publishing Venue

The IP.com Prior Art Database


In certain situations, the standard allow/deny output of the access control module are sub-optimal (e.g., if access to a resource is not to be fully denied, but limited). We propose to extend the (allow | deny) set to (allow | deny | allow_with_limitations). The new "allow_with_limitations" may serve a correspondigly extended logic to decide (per policy) on the limited access actions that are to be performed. The proposed method provides the framework for an enhanced storage access control mechanism that is more flexible and efficient (concise) than the state of the art.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 01 of 3

Extending the Output Values of Storage ACLs to Control Restricted Access

Field Topic:

The invention area is an access control module that is common in most computer systems. Typically, access to system resources is limited. Hence, prior to accessing a resource an access control module is invoked to query the access rights of the requesting process. This invention addresses the way the access control module functions.


Access control modules in computer systems carry the responsibility to permit/deny

access to system resources. Typically, the module receives as input various inputs that describe the access request and the requestor credentials, then it uses some policies to process the request, and eventually arrives at a conclusions whether to allow or reject the access request. The parameters of the access request typically include the accessed resource (e.g., disk file), the type of the requested access (e.g., write), the user attributes (e.g., user name, user group) and additional system specific input data. Depending on the access control methodology, these parameters are then compared to either policies or Access Control Lists (ACLs), which describe the access control rules. In file systems, ACLs are stored as part of the file i-node and contain a list of users and groups that are allowed to access the resource (e.g. POSIX ACLs). Recently, the NFSv4 standard (see RFC 3530) extended this model to ACLs containing lists of permissions-granting or permissions-denying entries called access control entries (ACEs). In this specification, ACEs were extended to the following 4 types: (1) ALLOW

- an entry specifying a condition which allows access. (2) DENY - an entry specifying the condition which denies access. (3) AUDIT - specifies when the access should be

reported to the audit LOG; (4) ALARM - specifies when the access should generate a

system alarm. The conditions required for the access control decision are described in the ACE fields "who", "flags" and "access_mask", which detail the users/groups, conditions (e.g. inheritance flags) and operations, respectively. Note that ACEs of type

ALARM and AUDIT do not affect the requester's access, and are used for triggering internal system events following an access attempt. Thus, even in the most advanced NFSv4 model of ACLs, the output of the access control decision is either allow or deny, and there is no support for restricted operations that grant the user a limited or restricted access. The current disclosure addresses this issue.

Alternative access control models are Role-based access control (RBAC), or

Attribute Based Access Control system (ABAC), which define policies specifying how to

deal with situations that are likely to occur via priorities and access control rules for various system resources. Policy management is usually centralized and most of the existing systems comprise a policy decision point (PDP) for interpreting the policies and a policy enforcement p...