Methods, systems, and products for governing access to objects on a filesystem. In one general embodiment, the method includes providing a framework in an operating system environment for support of a plurality of access control list (ACL) types, thereby enabling governing of access to objects on a filesystem according to an associated definition of an ACL type; and accepting definitions of ACL types. The associated definition may comprise a kernel extension.

BACKGROUND

Access to files in a filesystem may be controlled according to an access control list (‘ACL‘). An ACL may be used to specify access permissions to filesystem objects, such as files and directories. An ACL may include a list of many entries and different permissions to each of the entries. Each entry may define a user or a group.

SUMMARY

Methods, systems, and computer products for an extensible ACL framework are disclosed herein. Embodiments of the present disclosure may be implemented as a filesystem framework and kernel extensions. One general embodiment includes a computer-implemented method for governing access to objects on a filesystem including providing a framework in an operating system environment for support of a plurality of access control list (ACL) types, thereby enabling governing of access to objects on a filesystem according to an associated definition of an ACL type; and accepting definitions of ACL types.

Another general embodiment includes a computer-implemented method for controlling access to a filesystem. The method includes receiving a request to control access to a filesystem object with an access control list (ACL) of an ACL type corresponding to one of multiple ACL type definitions available in memory; and, in response to receiving the request to control access to the filesystem object using the ACL of the ACL type, controlling access to the object according to the ACL, and the ACL type definition. Controlling access to the object according to the ACL and the ACL type definition may be carried out by storing an indicator of the ACL type in association with the object; and, in response to receiving a request to access the object, retrieving the ACL type definition according to the indicator and governing access to the object according to the ACL and the retrieved ACL type definition. Another computer-implemented method for controlling access to a filesystem may include receiving an access control list (ACL) type definition defining the ACL type; and storing the access control list (ACL) type definition in memory.

Other general embodiments include a system for governing access to objects on a filesystem. The system comprises one or more computers comprising a processor and a computer memory operatively coupled to the processor. The computer memory of one or more of the computers has disposed within it computer program instructions for execution on the processor to implement one or more of the method embodiments described above.

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.

DETAILED DESCRIPTION

FIG. 1?sets forth a flow chart illustrating a method for governing access to objects on a filesystem according to embodiments of the present invention. Referring to?FIG. 1, the method includes two related tasks. The method comprises providing a framework in an operating system environment for support of a plurality of ACL types, the framework enabling governing of access to objects on a filesystem according to an associated definition of an ACL type (block?102); and accepting definitions of ACL types (block?104). Objects may include files, directories, or other software or hardware resources, such as device files. The various forms of access of, for example, a file may include depositing, reading, editing, copying, sharing, deleting, and so on.

Various operating systems and filesystems have provided support for various types of ACLs for controlling access to objects on a filesystem. An ACL type is a format of an ACL prepared by or for a specific ACL definition. The ACL definition specifies the scheme (including templates, formats, rules, etc.) for using an ACL to govern access of objects. For example. Network Filesystem version 4 (‘NFSv4‘), OpenAFS, Apple Filing Protocol (‘AFP‘) are filesystems providing support for ACLs of their respective types, and the AIX operating system from International Business Machines Corporation (Armonk, N.Y.) provides support for its own type of ACLs (‘AIXC ACLs‘) in its JFS filesystem and AIX JFS2 filesystem. Embodiments of the present disclosure include other types of ACLs that may be developed to better fit specific environments. For example, a partition-based ACL type may be used to restrict access (at least partly) in accordance with a partition ID of a virtual operating system environment partition. Role-based ACL types may be developed to restrict access according to role-based schemes. Partition and Role-based ACL types may be easily implemented using the framework dislosed herein. Custom designed ACL types (e.g. MyACL) may be developed for individual users, companies, and the like, and the definition for these custom designed ACL types may be added to the framework as a choice of ACL type.

The framework allows for the use of multiple ACL types across various applications in a single operating system. Providing a framework in an operating system environment for support of a plurality of ACL types (block?102) may be carried out by decoupling ACL type definitions from the base kernel of the operating system. ACL-related interfaces in kernel space and user space of the operating system are modified for integration with the framework. The framework implements filesystem functionality dependent upon ACL type. For example, the framework may effect functionality of specific ACL definitions through the use of virtual memory mapping of access governing functions of particular ACL definition implementations. Alternatively, the framework may use plug-ins or kernel extensions implementing access governing functions of a particular ACL definition. Another way to decouple ACL types from the kernel is by bringing all of the ACL based checks to user space just above the operating system kernel, for example, by implementing the ACL functionality in wrappers just above the system calls.

Accepting definitions of ACL types (block?104) may be carried out by storing modules comprising ACL type definitions, as is discussed in greater detail with reference to?FIG. 6A?below. The definitions may be in the form of kernel extensions that are stored in memory. The kernel extensions may be loadable kernel modules that dynamically alter the kernel at run time. The kernel extensions provide an ability to extend the services offered by the operating system kernel. In this particular case, kernel extensions may be plugged into the system to support new ACL types. Note that the kernel extensions define the new ACL types by providing interfaces to handle access checks related to those ACL types.

Embodiments of the presently disclosed invention are implemented to some extent as software modules installed and running on one or more data processing systems (‘computers‘), such as servers, workstations, tablet computers, PCs, mainframes, other managed systems, and the like.?FIG. 2?sets forth a block diagram of an exemplary computer?202. Computer?202?includes at least one computer processor?254?as well as a computer memory, including both volatile random access memory (‘RAM‘)?204?and some form or forms of non-volatile computer memory?250?such as a hard disk drive, an optical disk drive, or an electrically erasable programmable read-only memory space (also known as ‘EEPROM‘ or ‘Flash‘ memory). The computer memory may be connected through a system bus?240?to the processor?254?and to other system components. Thus, the software modules may be program instructions stored in computer memory.

An operating system?210?is stored in computer memory. Operating system?210?may be any appropriate operating system such as Windows XP. Windows Vista, Mac OS X, UNIX, LINUX, Sun Microsystems‘s Solaris, or AIX from International Business Machines Corporation (Armonk, N.Y.).

Computing device?202?may also include one or more input/output interface adapters?256. Input/output interface adapters256?may implement user-oriented input/output through software drivers and computer hardware for controlling output to output devices?272?such as computer display screens, as well as user input from input devices?270, such as keyboards and mice.

Computing device?202?may also include a communications adapter?252?for implementing data communications with other devices?260. Communications adapter?252?implements the hardware level of data communications through which one computer sends data communications to another computer through a network.

Also stored in computer memory is a filesystem framework module?208, which may operate at least partially in kernel space. The filesystem framework module?208?includes computer program instructions providing a framework in an operating system environment for support of a plurality of access control list (ACL) types as described herein. The module may include computer program instructions for receiving a request to control access to a filesystem object with an access control list (ACL) of an ACL type corresponding to one of multiple ACL type definitions available in memory, and computer program instructions for, in response to receiving the request to control access to the filesystem object using the ACL of the ACL type, controlling access to the object according to the ACL and the ACL type definition. The module may also include computer program instructions for receiving access control list (ACL) type definitions defining ACL types and storing the access control list (ACL) type definitions in memory.

Also stored in computer memory is kernel extension module?206, which may operate at least partially in kernel mode. The kernel extension module?206?includes computer program instructions implementing a definition of an ACL type as described herein. The module may include computer program instructions for governing access to files according to an ACL of a particular ACL type. Individual developers may develop their own kernel extension modules to define a desired ACL type. For example, the kernel extension may have hooks defined, such as "Add/Edit ACLs" hooks, which allows manipulation of defined ACL types; "Access Checks/Verification" hooks, which manage verification of ACL type; "Remove/Delete" hooks, which remove the ACL type; "Register/Install ACL Type" hooks, which register an ACL type with the kernel, and so on. The kernel extension module?206?may be dynamically loaded at runtime.

The filesystem framework module?208?may be incorporated in operating system?210, including in the kernel. The filesystem framework module?208?may be implemented as one or more sub-modules operating in separate software layers or in the same layer. Although depicted as being incorporated into the operating system?210?in?FIG. 2, the filesystem framework module?208?or one or more sub-modules making up the filesystem framework module?208?may be separate from the operating system?210. In particular, invocations of system calls may be implemented in high-level code, such as application code. For example, the request for access to filesystem objects could be made through the filesystem related system calls which are provided by the operating system kernel. In some embodiments, the filesystem framework module?208?may be implemented in the software stack, in hardware, in firmware (such as in the BIOS), or in any other manner as will occur to those of ordinary skill in the art.

FIG. 3?is a data flow diagram illustrating a method for governing access to objects on a filesystem in accordance with one embodiment of the invention. The system begins by receiving a request?304?to control access to a filesystem object?316with an ACL?310?of an ACL type corresponding to one of multiple ACL type definitions?314?available in memory (block?302). Receiving the request?304?to control access to the filesystem object?316?(block?302) may include receiving a request?304?to create or store the object?316. A request may be any of the following operations: create, read, write, execute, change ownership, change access times, change ACL content, and so on. In some implementations, the system is configured to interpret receiving a request to store an object?316?as a request to control access or receiving a request to store an object316?automatically generates a request?304?to control access of that object?316?with an ACL?310, such as in configurations wherein ACL?310?generation is a default operation of object?316?creation. In other implementations, a user choice in storage mechanisms or a specific command received through a command-line interface or the like generates the request?304. The request?304?to control access to the filesystem object?316?may pertain to an object?316?that has already been stored, possibly for a period of time longer than the duration of a typical user session, such as a period of days, weeks, or years.

In response to receiving the request?304?to control access to the filesystem object?316?using the ACL?310?of the ACL type, the system controls access to the object?316?according to the ACL?310?and the ACL type definition?314?(block?306). Controlling access to the object?316?according to the ACL?310?and the ACL type definition?314?(block?306) may include storing an indicator?318?of the ACL type in association with the object?316?(block?308). For example, the indicator?318?may be a keyed numerical value of the ACL type, a pointer, a flag in a bit position corresponding to the ACL type, a defined text value or variable name, and so on.

FIGS. 4A and 4B?illustrate data structures for storing an indicator?318?of the ACL type in association with the object. Referring to?FIG. 4A, file?400?comprises a group of mode bits?404. The extensible bit?402?signifies whether an ACL is associated with the object. In this instance, the extensible bit?402?is set to 1, indicating that an ACL is associated with the object.

Extended attributes are data structures that enable users to associate computer files with data not strictly defined by the filesystem. Indicators?318?may be stored in extended attributes. Referring to?FIG. 4B, extended attribute?450?includes names?452,?456,?460,?464,?468?paired with associated values?454,?458,?462,?466,?470. The names?452,?456,?460,?464,468?are indicators comprising a text value corresponding to predefined ACL types. The associated values?454,?458,?462,466,?470?comprise a pointer corresponding to memory addresses containing the ACL of the named type. For example, the names NFSv4?452?and MyACL?464?indicate the ACL types NFSv4 ACL and a custom ACL type named MyACL, respectively, that correspond to ACL type definitions available in memory. The names AIXC ACL?456, Partition ACL?460, and ROLE ACL?468?each correspond to null values?458,?462,?470, which indicate that ACLs of these types do not govern the file.

Returning to?FIG. 3, in response to receiving a request?304?to access the object?316, the system retrieves the ACL type definition?314?according to the indicator?318?and governs access to the object?316?according to the ACL?310?and the retrieved ACL type definition?314?(block?312). Retrieving the ACL type definition?314?according to the indicator?318?may be carried out by resolving the indicator?318. For example, if the indicator?318?is a keyed numerical value, retrieving the ACL type definition?314?according to the indicator?318?may include performing a lookup of the keyed numerical value in a lookup table and following a pointer associated with the keyed numerical value to the section of memory containing the ACL type definition?314.

Controlling access to the object according to the ACL and the ACL type definition (block?304) may be carried out through the framework.?FIGS. 5A and 5B?set forth a data flow diagram illustrating a framework for governing access to objects on a filesystem in accordance with embodiments of the invention.

Applications may invoke an instance of a filesystem operation system call?502, such as, for example, a create, open, rename, change ACL content, link, or unlink call, or any other filesystem related operations that may perform an access check as part of the operation. The instance of the filesystem operation system call?502, when invoked during execution, requests an execution of the create system call function?504?from the kernel. The create system call?504?utilizes ACL in governing access to files. Before performing the actual filesystem operation, the system call will first check if the user/process has permission to access the file or not. This will be done using the ACL framework?508. The create system call?504?makes a system call (506) to the framework?508?to perform access verification under any related ACL.

The framework?508?detects the indicator, for example, by reading mode bit?402, which is set to 1. The framework?508retrieves the indicator?510?of ACL type from storage, such as, for example, extended attribute?450. The framework?508also retrieves the ACL (or the pointer?512?specifying the ACL location?518) that corresponds to the ACL type?510. If a plurality of ACL types is defined, the framework retrieves each ACL type (and any ACLs corresponding to them).

For each ACL type?516?a,?516?b, the framework?508?has previously dynamically loaded a kernel extension implementing the ACL type definition. The kernel extension provides additional kernel services and system calls by specifying an export file when it is link-edited. This export file contains a list of symbols to be added to the kernel name space. When a new kernel extension is loaded, any symbols exported by the kernel extension are added to the kernel name space, and are available to all subsequently loaded kernel extensions. Similarly, system calls exported by a kernel extension are available to all applications or shared objects subsequently loaded. Function pointers dynamically load the kernel extension by linking?520a,?520?b?loadable kernel modules?530?a,?530?b?implementing the kernel extensions.

The loadable kernel modules?530?a,?530?b?may be Executable and Linkable Format (‘ELF‘) object files. Linking the object files resolve their symbols and results in executables. The loadable kernel module?530?a?exports calls, such as system call514?a, which provide the functionality of the ACL having the ACL type?516?a. The loadable kernel module?530?b?exports calls, such as system call?514?b, which provide the functionality of the ACL having the ACL type?516?b.

The framework, retrieving the indicator of ACL type?516?b, invokes the system call?514?b. The instance of system call?514b, when invoked, requests an execution of the access governing functions for ACL type?516?b?from the loadable kernel module?530?b. Upon determining access rights, the calls return to create system call?504.

FIG. 6A?is a flow chart illustrating a method for governing access to objects on a filesystem in accordance with one embodiment of the invention. The method comprises receiving an ACL type definition defining the ACL type (block?602), and storing the ACL type definition in memory (block?604). Receiving an ACL type definition defining the ACL type (block?602) may be carried out by receiving the ACL type definition as a file. Storing the ACL type definition in memory (block?604) may comprise storing the ACL type definition in long-term non-volatile memory. The memory footprint for the kernel may be minimized by loading only those elements (definitions) that are needed into active memory.

FIG. 6B?is a flow chart illustrating a method for governing access to objects on a filesystem in accordance with one embodiment of the invention. The method comprises receiving an ACL type definition defining the ACL type (block?602), and storing the ACL type definition in memory (block?604), as described above in reference to?FIG. 6A. The method further comprises receiving a request to control access to a filesystem object with an ACL of an ACL type corresponding to one of multiple ACL type definitions available in memory (block?302); and controlling access to the object according to the ACL and the ACL type definition (block?306), as described above with reference to?FIG. 3. The method of?FIG. 6B?allows for external definition of ACL types and facilitation of implementing the externally defined ACL type by an ACL framework.

It should be understood that the inventive concepts disclosed herein are capable of many modifications. To the extent such modifications fall within the scope of the appended claims and their equivalents, they are intended to be covered by this patent.

SRC=https://www.google.com.hk/patents/US20110125799