Abstract:
A simulated access environment overrides function calls pertaining to resources for which the user may be restricted from accessing. The environment also allocates and manages replacement resources that are used in place of access-restricted computing resources in order to enable execution of utilities or applications that would normally abort without enhanced user permissions. In one embodiment, replacement resources are managed by a resource mirror. In certain embodiments, the function calls are statically overridden by linking a replacement library to the utilities or applications. In other embodiments, the function calls are dynamically overridden via software interrupts, replacing entries within a function table, dynamically loading a replacement library, or the like.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to systems for testing software applications and more particularly relates to simulating permission-based access to computing resources. 
     2. Description of the Related Art 
     Considerable effort is required to design and develop software applications that perform effectively under a wide variety of conditions. Often, in an attempt to improve the effectiveness of specific functions, coding changes are made that behave differently than expected. Additionally, changes to one module of code may have unexpected effects on related modules. Furthermore, in some development environments such as an open source development environment, a large number of developers may make changes to the source code. 
     One method to deal with the dynamic nature of application development and find coding errors is to conduct a build and test sequence at regular intervals.  FIG. 1  is a schematic block diagram depicting one embodiment of a prior art build and test system  100 . As depicted, the build and test system  100  includes a user environment  110 , a build script  115 , a test script  120 , one or more applications  130 , a system level interface  140 , and a set of resources  150  such as files  152 , directories  154 , devices  156 , pipes  158 , and processes  159 . The build and test system  100  may be used to build and test applications under development and thereby identify coding errors, and the like, previous to general distribution of the applications. 
     The user environment  110  interacts with the user and may respond to commands and interface events involving the user. The user environment allows a user or administrator to define system level variables and parameters such as pathnames and user preferences. In certain implementations, the user environment  110  includes a command shell (not shown) that provides a command line prompt and responds to system level commands input by the user. In one embodiment, the command shell responds to user requests to list directories, view file permissions, and the like. 
     The build script  115  may retrieve or reference source code (not shown) and invoke a compiler to compile the source code into an executable application  130 . In one embodiment, the build script  115  retrieves the latest revision of source code from a source code control system (not shown), and places the code in a designated directory and compiles the code into an executable file  130 . After the application is built, the test script  120  executes and exercises the application  130  to find coding errors and may log results from such exercises into a test log (not shown). In conjunction with executing and exercising the application  130 , an install process may be conducted to install the application. 
     The system level interface  140  is typically provided by the operating system and facilitates access to a set of resources  150  such as files  152 , directories  154 , devices  156 , pipes  158 , and processes  159 . Many applications are constructed in a manner that requires access to restricted resources in order to properly build the application. For example, the build process may change system level files that are protected from access by ordinary users. However, the build and test process is sometimes conducted by ordinary users—particularly in an open source development environment where testing may be conducted by an unknown or unfamiliar party. In such a scenario, the build process may be aborted due to the insufficient privileges of the user. 
     One prior art solution to such a scenario imitates supervisor or root privileges for an ordinary user without actually securing such privileges. While this may be useful in certain instances and allow program flow to continue further than usual, such a solution will typically fail when a restricted resource is actually accessed. 
     Another prior art solution involves developing “relocatable” source code which uses relative references to computing resources and may be executed from an arbitrary location or directory. However, developing relocatable source code is a fairly tedious process that further complicates the testing process by introducing additional variables. Additionally, large programming projects may integrate modules maintained by external parties that do not support relocation. Furthermore, distributing a relocatable application may be undesirable due to licensing and security issues. 
     Given the aforementioned issues and challenges, what is needed are methods and systems to simulate access to restricted resources without actually using the restricted resources. 
     SUMMARY OF THE INVENTION 
     The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available build and test means and methods. Accordingly, the present invention has been developed to provide an apparatus, system, and method to simulate access to restricted computing resources that overcomes many or all of the above-discussed shortcomings in the art. 
     In one aspect of the present invention, an apparatus to simulate access to restricted computing resources includes at least one replacement function configured to override a function call related to the potentially restricted computing resources, and a resource mirror configured to allocate accessible resources corresponding to access-restricted computing resources (i.e. resources that are inaccessible to the current user). Allocating accessible replacement resources facilitates building and testing an application without actually accessing restricted computing resources. 
     The apparatus may also include a function interceptor that intercepts function calls related to potentially restricted computing resources. In certain embodiments, the function interceptor first invokes an original function call and then invokes a replacement function if the original function call fails. In one embodiment, the function interceptor is essentially a library of replacement functions that is linked in during a build sequence. In another embodiment, the function interceptor dynamically traps function calls related to access-restrictable computing resources and replaces references to access-restricted computing resources with references to corresponding resources that are accessible by the user. 
     Examples of computing resources that may be restricted include files, directories, devices, processes, and pipes. Examples of function calls that may attempt to access-restricted computing resources include file system calls, system control calls, interprocess communication calls, and device driver calls. 
     The apparatus to simulate access to restricted computing resources may further include an environment configured to interact with a user. The environment may include a simulated access shell that invokes the function interceptor or is linked to a library of replacement functions instead of a standard system library. Accordingly, the simulated access shell may appear to the user and the applications launched by the user as a standard shell while leveraging the replacement functions that access accessible computing resources in lieu of restricted computing resources. 
     In another aspect of the present invention, a method to simulate access to restricted computing resources includes providing a replacement function configured to override a function call related to access-restrictable computing resources, and allocating an accessible resource corresponding to a restricted computing resource. In certain embodiments, the function calls are statically overridden by linking a replacement library to the utilities or applications. In other embodiments, the function calls are dynamically overridden via software interrupts, replacing entries within a function table, dynamically loading a replacement library, or the like. 
     The method may also include invoking a replacement function in response to a failed function call and/or intercepting the function call and replacing references to access-restricted computing resources with references to accessible computing resources. Additionally, the method may also include switching the current user to an arbitrary user. 
     Various elements of the present invention may be combined into a system to simulate access to restricted computing resources. In one embodiment, the system includes a digital processing unit configured to execute programs, an operating system, a storage device, and a simulated access environment that overrides function calls involving access-restricted computing resources, and allocates accessible resources corresponding to the access-restricted computing resources. 
     The present invention provides benefits and advantages over currently available solutions. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features and advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment. 
     Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention. 
     These features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which: 
         FIG. 1  is a schematic block diagram depicting one embodiment of a prior art build and test system; 
         FIG. 2  is a schematic block diagram depicting one embodiment of a simulated access build and test system of the present invention; 
         FIG. 3  is a schematic block diagram depicting one embodiment of an unrestricted access simulator of the present invention; 
         FIG. 4  is a schematic flow chart diagram depicting one embodiment of an unrestricted access method of present invention; 
         FIG. 5  is a schematic flow chart diagram depicting one embodiment of a build and test method of the present invention; and 
         FIG. 6  is a schematic flow chart diagram depicting an alternate embodiment of the unrestricted access method of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. 
     Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module. 
     Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory or storage devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different memory or storage devices. 
     Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment. 
     Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention. 
     The present invention addresses the needs and challenges described in the background section such as those depicted in  FIG. 1 . Specifically, the present invention provides a system, apparatus, and method to simulate access to restricted resources that allocates and manages accessible resources in place of restricted resources. Allocating and managing accessible resources allows a build and test process, or a similar process, to proceed as if the user had accessed the restricted computing resources. 
       FIG. 2  is a schematic block diagram depicting one embodiment of a simulated access build and test system of the present invention. The build and test system  200  includes a simulated access environment. The depicted embodiment also includes as a build script  115 , a test script  120 , one or more applications  130 , a system level interface  140 , and a set of resources  150  such as files  152 , directories  154 , devices  156 , pipes  158 , and processes  159 . While using many of the same elements in a backward compatible manner, the build and test system  200  provides additional functionality over prior art solutions. 
     The simulated access environment  210  provides an environment that appears as a conventional computing environment for building and testing applications such as the user environment  110  depicted in  FIG. 1 . In addition, the simulated access environment  210  traps or replaces function calls made by the applications  130  regarding potentially restricted resources  150  and allocates accessible computing resources  150   b  that are accessed in lieu of restricted computing resources  150   a . In certain embodiments, the simulated access environment  210  also maps subsequent access to the restricted computing resources to the allocated replacement resources. 
     For example, a function call that attempts to write to a system file for which the user lacks permission may be redirected to a file allocated by the simulated access environment  210 . Instead of returning an error and causing a build and test process to abort or malfunction, an actual write operation would occur to an accessible replacement resource. Using accessible replacement resources facilitates building and testing applications by users who generally lack sufficient privileges to use restricted computing resources while maintaining the security of the computing system from malicious or ignorant users. Consequently, accessing the replacement resources generally provides the same result as accessing the initial resources. 
       FIG. 3  is a schematic block diagram depicting one embodiment of an unrestricted access simulator  300  of the present invention. The unrestricted access simulator  300  is a specific implementation of portions of  FIG. 2 . For instance, An execution As depicted, the unrestricted access simulator  300  includes an execution shell  310 , a function interceptor  320 , a set of replacement functions  322  and original functions  324 , a resource mirror  330  with a resource table  332 , and a set of replacement resources,  150   b  and original resources  150 . The unrestricted access simulator  300  is a specific implementation of portions of  FIG. 2 . For instance, the execution shell  310 , the function interceptor  320 , and the resource mirror  330  may implemented within the simulated access environment  210 . The unrestricted access simulator  300  allocates and manages replacement resources  150   b  in lieu of original resources  150  and in some cases may replace original system functions  324  with replacement functions  322 . 
     The execution shell  310  interacts with the user and responds to commands or interface events generated by the user. For example, a user may type in a command to execute a script or application. In the depicted embodiment, the execution shell  310  launches the requested script or application via system calls. System calls involving restrictable computing resources may be directed to the function interceptor  320 . As used in ths document, the term “restrictable resources” is intended to mean resources from which the user may be restricted from accessing but is not necessarily restricted from accessing. The function interceptor  320  may invoke the replacement functions  322  as well as the original functions  324 . In one embodiment, a replacement function  322  is invoked only if an original function  324  produces an error. 
     The function interceptor (module)  320  or the replacement functions  322  may generate an allocation request  326  or a map resource request  328  to the resource mirror  330 . The resource mirror  330  (alternately referred to as the resource allocation module  330 ) allocates replacement resources  150   b  and responds to the allocation requests  326  and the map resource requests  328 . In the depicted embodiment, the resource mirror  330  manages a resource table  332  that maps each reference to an original resource  150   a  (that is restricted from access) to a corresponding replacement resource  150   b . The depicted resource mirror  330  also provides an allocation acknowledgment  336  in response to an allocation request  326  or a replacement resource reference  338  in response to a map resource request  328 . 
       FIG. 4  is a schematic flow chart diagram depicting one embodiment of an unrestricted access method  400  of present invention. As depicted, the unrestricted access method  400  includes providing  410  replacement functions, intercepting  420  a function call, invoking  430  an original function, testing  440  for an error, allocating  450  replacement resources, and invoking  460  a replacement function. The unrestricted access method may be conducted in conjunction with, or independent of the unrestricted access simulator  300  depicted in  FIG. 3 . 
     The method  400  begins by providing  410  replacement functions related to potentially restricted resources. In certain embodiments, the replacement functions are provided within a code library that is used to compile the applications  130 . In one embodiment, the code library selectively overrides original functions (such as those that pertain to access-restrictable computing resources) with replacement functions. 
     The method  400  continues by intercepting  420  a function call. In one embodiment, intercepting  420  is accomplished with a software trap. In another embodiment, a pointer within a function table or object is redirected to point to an intercepting function. In the depicted embodiment, the method continues by invoking  430  an original function and testing  440  for an error. If no error occurs, the method  400  loops to the intercept step  420 , otherwise the method continues by allocating  450  replacement resources and invoking  460  a replacement function. 
     In the depicted embodiment, the method continues by testing  470  for an exit request. The exit request may generated, for example, by a user who is logging off, or by a system that is shutting down. In response to an exit request the method ends  470 . If no exit request is pending the method loops to the intercept step  420  and continues the process of testing for function call errors, and allocating replacement resources and invoking replacement functions in response to such errors. 
       FIG. 5  is a schematic flow chart diagram depicting one embodiment of a build and test method  500  of the present invention. As depicted, the build and test method  500  includes launching  510  an environment, building  520  one or more applications, executing  530  the applications, and exiting  540  the launched environment. The build and test method  500  may be used in conjunction with the build and test system  200 , or may be conducted independent thereof. 
     The build and test method  500  begins by launching  510  an environment such as the environment  210  that simulates access to restricted computing resources. The depicted method  500  continues by building  520  one or more applications. In one embodiment, building  520  one or more applications includes providing a replacement library with function names that are identical to a standard system library and linking the replacement library to an application via the build script  115 . Linking the replacement library to an application facilitates selectively replacing original functions with replacement functions. In another embodiment, the replacement library is dynamically linked to a replacement library and the build step  520  is omitted. 
     The build and test method  500  continues by executing  530  one or more applications. Executing  530  one or more applications may include executing a test script or exercising the applications in an automated or non-automated manner. Executing  530  may also include switching the current user to another (arbitrary) user. The ability to switch to an arbitrary user provides additional functionality over prior art solutions that are typically restricted to assuming superuser privileges. Subsequent to step  530 , the user or script may log off and exit  540  the launched environment. 
       FIG. 6  is a schematic flow chart diagram depicting an alternate embodiment of the unrestricted access method  400  of the present invention namely an alternate access method  600 . As depicted, the alternate access method  600  includes inspecting  610  a parameter, testing  620  for a restricted resource, allocating  630  an unrestricted resource, replacing  640  the parameter, testing  650  for more parameters and invoking  660  an original function. The alternate access method  600  facilitates using replacement resources without the use of replacement functions in environments where the system level code is not open for modification. 
     The alternate access method  600  may be conducted in conjunction with the function interceptor  320  depicted in  FIG. 3 . In conjunction with intercepting a function call that may pertain to restricted computing resources, the alternate access method  600  begins by inspecting  610  a parameter for reference to a restricted resource. The method  600  continues by testing  620  for a restricted resource. If a restricted resource is not referenced, the method skips to the more parameters test  650 . If a restricted resource is referenced, the method continues by allocating  630  an unrestricted resource. 
     Allocating  630  an unrestricted resource may include accessing the resource table  332  to ascertain whether an accessible resource  150   b  corresponding to a (restricted) original resource  150   a  has already been allocated and allocating an accessible resource  150   b  if one has not been allocated. Subsequently, the method continues by replacing or changing  640  the parameter to reference the accessible computing resource. The method continues by testing  650  whether all the parameters of the function call have been processed. 
     If more parameters need to be processed the depicted method loops to the inspect parameter step  610 . If no more parameters need to be processed the method continues by invoking  660  the original function. Invoking  660  preferably includes using replacement parameters (provided by step  640 ) that reference accessible resources instead of resources that are restricted from access by the user. 
     The present invention simulates access to restricted computing resources by allocating accessible replacement resources and redirecting access to restricted computing resources to the replacement resources. The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.