STACKABLE FILE SYSTEM WITH USER SPACE POLICY MANAGEMENT

Abstract

A computing device and method for managing file access control policies on a computing device are disclosed. The method includes maintaining file-access policies in user space, receiving, at a kernel level, from a user in user space, a request to access a file, and directing the request from the kernel level to a file-policy manager in user space. At least one of the of the file-access policies is enforced in user space with the file-policy manager to grant or deny access to the file, and file operations are performed on the file using only kernel-level calls when access to the to the file is granted.

Description

BACKGROUND

I. Field of the Disclosure

The technology of the disclosure relates generally to file management, and more particularly to file system policy management.

II. Background

Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file owner, file group, and other. But the protection actually provided depends on the type of file system that is implemented. Some file systems such as file allocation table (FAT) systems do not support such permissions at all. There are a large number of cases where this policy is not really enough and might need to simply add additional checks or automatically enforce permissions on certain files or directories. So there is a need for an additional layer to provide the same view or add to the current file system without actually modifying the file system itself.

On ANDROID-based devices, an external SD card and the emulated internal SD card are mounted using a file-system-in-user-space (FUSE) file system. This allows ANDROID-based devices to enforce special policies for these mount points. But this comes at a cost of performance because FUSE file systems require that all operations go through user space, and thus, every read and write needs to make six context switches to complete. Benchmarking studies have shown that this approach may be slower than actually reading/writing to the lower file system.

Original equipment manufacturers have developed file systems that allow the entire policy and file operations to be part of the kernel, and thus, these systems can achieve very close to native file system performance while still adding policy and other enforcements. But the simplicity of user space management is lost, and there is a large overhead of maintaining policy in the kernel because any change to policy requires kernel changes.

SUMMARY

Embodiments disclosed herein address the above stated needs by providing a method for managing file access control policies on a computing device. The method includes receiving, at a kernel level, from a user in user space, a request to access a file, and directing the request from the kernel level to a file-policy manager in user space. A file-access policy is enforced with the file-policy manager to grant or deny access to the file, and file operations are performed on the file using only kernel-level calls when access to the file is granted.

Another aspect may be characterized as a computing device that includes at least one storage device configured to store files, and a kernel-level file system configured to enable operations on the stored files. At least one application is configured to send a request for access to one or more of the stored files, and a stackable policy file system is configured to operate at the kernel-level and redirect the request for access to user-space. The computing device also includes a file-policy manager configured to receive the request for access in user-space and enforce file-access policies in user space to grant or deny access to the stored files and provide a grant-indicator to enable the application to perform input/output operations on the one or more files with the kernel-level file system without communicating with the user space.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting an embodiment described herein;

FIG. 2 is a block diagram depicting another embodiment;

FIG. 3 is a method that may be traversed in connection with embodiments described herein;

FIG. 4 is a diagram depicting communication flow that occurs in connection with the embodiment depicted in FIG. 1 in accord with the method shown in FIG. 3;

FIG. 5 is a diagram depicting communication flow that occurs in connection with the embodiment depicted in FIG. 2 in accord with the method shown in FIG. 3;

FIG. 6 is a diagram depicting physical components that may be used in connection with realizing embodiments described herein; and

FIG. 7 is a drawing depicts resultant aspects of embodiments disclosed herein.

DETAILED DESCRIPTION

The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

Referring to FIG. 1, shown is a block diagram of a computing device 100 that implements an exemplary file-system-policy management system. The computing device 100 may be realized by computing devices such as smart phones, tablets, netbooks, etc. As shown, the computing device 100 includes a user space portion and a kernel portion. Although the methodologies described herein are generally applicable to a variety of different types of operating systems and user space environments, for exemplary purposes, embodiments are described herein in the context of a modified LINUX kernel and modified ANDROID user space framework.

As shown, a kernel-level stackable policy file system (stackable policy FS) 102 is utilized with a file-policy manager 104 residing in user space. According to an aspect, policy is enforced by the file-policy manager 104 in user space while time consuming input/output (I/O) operations (such as and reads and writes) are performed at the kernel level without utilizing user space constructs. In the embodiment depicted in in FIG. 1 for example, file policies are maintained in a policy store 106 in user space, and open and create calls propagate through the file-policy manager 104, but a high level of performance is still maintained because read and write operations go directly to the kernel-level file system 108. Also depicted in FIG. 1 is an application 110 that resides in user space and storage 112 at a hardware level.

The application 110 is representative of any of a variety of processes that reside in user space, and each process may have a user ID and one or more group IDs. The application 110, for example, may be a gaming application, utility application, education application, entertainment application etc. The kernel-level file system 108 may be realized by, for example, a fourth extended file system (EXT4), file allocation table (FAT), or a network file system (NFS). As shown, the storage 112 may include N storage devices that each may be either a volatile or non-volatile storage device. The volatile type of storage devices may include random access memory (RAM) and the non-volatile storage devices may include flash memory (e.g., NAND type flash memory), removable flash memory (e.g., an SD card), or a network file system.

The stackable policy FS 102 generally operates to receive file access requests 114 from the application 110, and send the requests 114 as redirected requests 114 to the file-policy manager 104 that resides in user space. Requests 114 that may require a policy check, for example, may be an open call, a create request, an open directory call, lookup/stat, or a request to set an attribute. Although some requests 114 may not traditionally require policy checks, an aspect of the present embodiment is that it enables the creation of dynamic file policies that may be customized and dynamically updated by a user and stored in the policy store 106.

For example, an operator of the computing device 100 may create file-access policies that enable a user to access particular image files created within the last 24 hours while prohibiting access to other image files. As another example, a particular application developer may create policies to enable multiple applications (created by the developer) to access particular files while precluding other applications from accessing the files. Some examples of request types where file-access policies may be enforced are open, create, open-directory, set-attribute, and lookup/stat requests.

Upon receiving a redirected request 114, the file-policy manager 104 grants or denies the request by determining whether the stored file policies in the policy store 106 allow or prohibit the requested operation. The file-policy manager 104 then sends a response 116 (e.g., a grant indicator or denial indicator) that is received and routed by the stackable policy FS 102 back to the application 110. For example, the response may be a simple Boolean true or false indicator that indicates whether the request 114 is granted or denied, respectively.

If a request 114 is granted, the stackable policy FS 102 enables I/O requests 118 to pass through the stackable policy file system 102 to the kernel-level file system 108. In other words, the application 110 may then communicate with the kernel level directly without doing a policy check to perform a requested I/O action.

Granted file operations that pass through to the stackable policy FS 108 may include, for example, read requests, write requests, memory-mapped I/O, readdir, seekdir, seek, and an input/output control operation. Thus, the file-policy manager 104 only performs an initial policy check to enforce the file access policies and is not involved in the I/O requests 118 for file operations. As a consequence, file operations in the present embodiment, such as read and write requests, may be performed in a fraction of the time that the operations take in connection with the prior art FUSE approach.

In many implementations, the file-policy manager 104 may be realized as a background daemon that operates in the background without being readily apparent to an operator of the computing device 100. The file-policy manager 104 may be implemented as library may be shared by multiple processes. The file-policy manager 104 may also be implemented by a dynamically linked library.

The stackable policy file system 102 may be realized by modifying the LINUX kernel to function as describe herein. Although not shown for simplicity, those of ordinary skill in the art will appreciate that a LINUX virtual file system (VFS) exists within the kernel above the stackable policy FS 102.

Referring next to FIG. 2, shown is another embodiment of a computing device 200. As shown, in this embodiment the user space policy enforcement and direct-kernel I/O request functionality described with reference to FIG. 1 is implemented by extending and modifying FUSE constructs known in the art. More specifically, the file-policy manager 204 may be implemented by modifying the FUSE daemon that is known in the art, and the kernel-level FUSE module 222 known in the art is extended to capture lower-level file descriptors. Again the virtual file system (VFS) that is inherent to the LINUX kernel is not shown for clarity, but the VFS is interposed between the application 110 and FUSE 222 as discussed further herein.

Referring next to FIG. 3, shown is a flowchart depicting a method that may be traversed in connection with the embodiments described with reference to FIGS. 1 and 2. While referring to FIG. 3, simultaneous reference is made to FIGS. 4 and 5, which depict communication sequences in connection with the embodiments shown in FIGS. 1 and 2, respectively. As shown, file access policies relative to files in the storage 112 are maintained in user space in the policy store 106 (Block 302), and when a request to access one of the files is received at the kernel level (e.g., by the stackable policy FS 102 or FUSE module 222)(Block 304), the request is directed to the file-policy manager 104, 204 in user space (Block 306) where policy is enforced in user space to grant or deny access to the file (Block 308).

Referring briefly to FIG. 4, shown is a communication sequence that may occur in connection with the embodiment depicted in FIG. 1. While referring to FIG. 4, reference is also made to FIG. 7, which depicts aspects of results of the method depicted in FIG. 4. As shown, the request and policy enforcement is shown as step 1 and the communications that are carried out in connection with I/O activity are shown as step 2. When a request (e.g., from a process associated with the application 110) to access the file is received by the stackable policy FS 102, the request is directed to the file-policy manager 104 in user space where policy enforcement 400 is performed. In the depicted embodiment, policy enforcement is either granted (as shown by the path labeled “T”) or denied (as shown by the path labeled “F”).

As shown, if the request is granted, an “open” file operation request is made directly from the stackable policy FS 102 to the file system 108, and the file system 108 returns a lower-level file object reference (LLFO-reference) that points to the lower-level file object. In turn, the stackable policy FS 102 provides a stackable policy file object reference (SPFO-reference) that points to a stackable-policy file object (SPFO object). VFS then places the SPFO-reference in a file table associated with the process of the application 110. VFS also provides an indication of the open result to the application 110 and returns an index of an entry in the file table as a file descriptor (e.g., an integer between 0 and N) so the application 110 may perform I/O operations on the file object using the file descriptor. In the example depicted in FIG. 7, the SPFO-reference is indexed by the integer 0; thus the application 110 uses 0 as the file descriptor. One of ordinary skill in the art recognizes that the references described herein (e.g., SPFO-reference and LLFO-references) are pointers (e.g., addresses) to corresponding file objects (e.g., the SPFO and LLFO). In the example, shown in FIG. 7, the SPFO-reference is stored among other references in the process file table for a process associated with the application 110.

As shown in step 2 of FIG. 4, when performing file operations (e.g., read requests, write requests, memory-mapped I/O, readdir, seekdir, seek, and an input/output control operation), only kernel-level calls are utilized. As shown in FIG. 4, when a write request with the file descriptor is sent to the VFS, the VFS uses the file descriptor as an index to obtain the SPFO-reference and redirects the write request to the SPFO created by the stackable policy FS 102, which in turn, redirects the write request (along with the LLFO-reference) to the file system 108; thus avoiding interaction with the file-policy manager 104 in user space. As shown in FIG. 7, in connection with the write request, a process may use the file descriptor 0 as an index to the SPFO-reference in the process file table associated with the application 110. As shown, the SPFO-reference points to the stackable policy file system object (SPFO) (created by the stackable policy FS 102) where the LLFO-reference is located. As shown in FIG. 4, the write result from the file system 108 is then propagated back to the application 110 via the stackable policy FS 102 and the VFS.

In contrast, as shown in FIG. 5, when a request 114 to access a file is made in the embodiment depicted in FIG. 2, the request 114 is received by VFS and then directed to the kernel-level FUSE module 222, which redirects the request 114 to the file-policy manager 204 where policy enforcement 500 is performed. As shown in FIG. 5 in connection with an “open” request that is granted access at 500, the granted request is propagated to the kernel level file system 108, which returns an “open result” indication that includes an LLFO-reference to the file object (the opened file). The process file tables described in connection with FIGS. 2 and 5 are not shown, but like the process file table in FIG. 7, each process file table includes an index to a reference as described below.

Referring to FIGS. 2 and 5, VFS places this LLFO-reference in a process file table associated with the file-policy manager 204, and a lower-level file descriptor (LLFD) is provided as an index to the LLFO-reference at 502. In other words, this lower-level file descriptor is captured at 502 by the file-policy manager 204, and an open response is propagated with the lower-level file descriptor to the FUSE module 222 so the FUSE module 222 may extract the LLFO-reference from the process file table of the file-policy manager 204 (using the LLFD as an index). The FUSE module 222 creates a FUSE file object (FFO) that includes the LLFO-reference, and VFS places an FFO-reference in a process table associated with a process of the application 110 so that a file descriptor is associated (as an index) to the FFO-reference.

As depicted as step 2 in FIG. 5, when an I/O operation (e.g., a write operation) is requested using the file descriptor as an index, the FFO-reference is obtained (from the process table associated with a process of the application 110). The LLFO-reference is then obtained from the FUSE file object (FFO)(a file object in memory created by the FUSE module 222); thus enabling the request to be sent to the file system 108 (using the obtained LLFO-reference) without a context change to user space.

Thus, in both the embodiments depicted in FIGS. 1 and 2, I/O file operations are performed using only kernel-level calls when access is granted (Block 310). As a consequence, policies are enforced in user space (where policies may be easily initiated and changed) while performance is enhanced because operations (e.g., read and write operations) that would be time consuming if redirected through user space go directly to the native filesystem instead.

Referring to FIG. 6, shown is a block diagram depicting physical components that may be utilized to realize the one or more aspects of the embodiments disclosed herein. As shown, in this embodiment a display portion 1212 and nonvolatile memory 1220 are coupled to a bus 1222 that is also coupled to random access memory (“RAM”) 1224, a processing portion (which includes N processing components) 1226, a field programmable gate array (FPGA) 1227, and a transceiver component 1228 that includes N transceivers. Although the components depicted in FIG. 6 represent physical components, FIG. 6 is not intended to be a detailed hardware diagram; thus many of the components depicted in FIG. 6 may be realized by common constructs or distributed among additional physical components. Moreover, it is contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG. 6.

This display portion 1212 generally operates to provide a user interface for an operator of the computing device 100, 200. The display may be realized, for example, by a liquid crystal display or AMOLED display, and in several implementations, the display is realized by a touchscreen display to enable the operator of the computing device 100, 200 to enter file-access policies. In general, the nonvolatile memory 1220 is non-transitory memory that functions to store (e.g., persistently store) data and processor executable code (including executable code that is associated with effectuating the methods described herein). In some embodiments for example, the nonvolatile memory 1220 includes bootloader code, operating system code, file system code, and non-transitory processor-executable code to facilitate the execution of the functionality of the components described with reference to FIGS. 1 and 2.

In many implementations, the nonvolatile memory 1220 is realized by flash memory (e.g., NAND or ONENAND memory), but it is contemplated that other memory types may also be utilized. Although it may be possible to execute the code from the nonvolatile memory 1220, the executable code in the nonvolatile memory is typically loaded into RAM 1224 and executed by one or more of the N processing components in the processing portion 1226. In addition the file objects described herein may reside in RAM 1224. Both nonvolatile memory 1220 and RAM may be used to realize one or more of the storage devices depicted in the storage of FIGS. 1 and 2. In addition, the non-volatile memory 1220 may be utilized to realize the policy store 106 depicted in FIG. 1.

The N processing components in connection with RAM 1224 generally operate to execute the instructions stored in nonvolatile memory 1220 to enable the file system policy management described herein. For example, non-transitory processor-executable instructions to effectuate the file system policy management may be persistently stored in nonvolatile memory 1220 and executed by the N processing components in connection with RAM 1224. As one of ordinarily skill in the art will appreciate, the processing portion 1226 may include a video processor, digital signal processor (DSP), graphics processing unit (GPU), and other processing components.

In addition, or in the alternative, the FPGA 1227 may be configured to effectuate one or more aspects of the methodologies described herein. For example, non-transitory FPGA-configuration-instructions may be persistently stored in nonvolatile memory 1220 and accessed by the FPGA 1227 (e.g., during boot up) to configure the FPGA 1227 to effectuate one or more functions of the components depicted in FIG. 1.

The depicted transceiver component 1228 includes N transceiver chains, which may be used for communicating with external devices via wireless or wireline networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme (e.g., WiFi, CDMA, Bluetooth, NFC, etc.). The transceiver chains may be utilized to receive video frames that are processed (encoded or decoded) as described herein, and may be used to send video frames to another device.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for managing file access control policies on a computing device, the method comprising: receiving, at a kernel level, from a user in user space, a request to access a file;directing the request from the kernel level to a file-policy manager in user space;enforcing a file-access policy with the file-policy manager to grant or deny access to the file; andperforming file operations on the file using only kernel-level calls when access to the to the file is granted.

2. The method of claim 1, including: storing, with a stackable policy file object, in response to access to the file being granted, a lower-level file object reference;associating a file descriptor with a stackable policy file object reference in a process file table in the user space;obtaining, in connection with a file operation, the stackable policy file object reference to locate the stackable policy file object; andextracting the lower-level file object reference to access the lower level file object.

3. The method of claim 1, including receiving file-access policy updates from an operator and updating the file-access policies file-access policies in user space.

4. The method of claim 1, wherein the request to access the file is a request selected from the group consisting of: an open, create, open-directory, set-attribute, and lookup/stat request.

5. The method of claim 1, wherein the file operations are operations selected from the group consisting of a read, write, memory-mapped I/O, readdir, seekdir, seek, and an input/output control operation.

6. A computing device comprising: at least one storage device configured to store files;a kernel-level file system configured to enable operations on the stored files;at least one application configured to send a request for access to one or more of the stored files;a stackable policy file system configured to operate at the kernel-level and redirect the request for access to user-space;a file-policy manager configured to: receive the request for access in user-space and enforce file-access policies in user space to grant or deny access to the stored files; andprovide a grant-indicator to enable the application to perform input/output operations on the one or more files with the kernel-level file system without communicating with the user space.

7. The computing device of claim 6, wherein the stackable policy file system is configured to capture a lower-level file object reference for the one or more stored files.

8. The computing device of claim 6, including a policy store in user space configured to enable users to update file-access policies in the policy store.

9. The computing device of claim 6, wherein the kernel-level file system is selected from the group consisting of fourth extended file system (EXT4), file allocation table (FAT), and a network file system (NFS).

10. The computing device of claim 6, wherein the kernel-level is a modified LINUX kernel that is modified to include the stackable policy file system.

11. The computing device of claim 10, wherein the user space includes an ANDROID framework, and the file-policy manager is configured to operate as a background daemon in user space.

12. A non-transitory, tangible processor readable storage medium, encoded with processor readable instructions to perform a method for managing file access control policies on a computing device, the method comprising: receiving, at a kernel level, from a user in user space, a request to access a file;directing the request from the kernel level to a file-policy manager in user space;enforcing a file-access policy with the file-policy manager to grant or deny access to the file; andperforming file operations on the file using only kernel-level calls when access to the to the file is granted.

13. The non-transitory, tangible processor readable storage medium of claim 12, the method including: obtaining, in response to access to the file being granted, a lower-level file descriptor for the file; andutilizing the lower-level file descriptor to perform file operations on the file using only kernel-level calls.

14. The non-transitory, tangible processor readable storage medium of claim 12, the method including receiving file-access policy updates from an operator and updating the file-access policies.

15. The non-transitory, tangible processor readable storage medium of claim 12, wherein the request to access the file is a request selected from the group consisting of: an open, create, open-directory, set-attribute, and lookup/stat request.

16. The non-transitory, tangible processor readable storage medium of claim 12, wherein the file operations are operations selected from the group consisting of a read, write, memory-mapped I/O, readdir, seekdir, seek, and an input/output control operation.