Abstract:
A method for monitoring access to a file within a file system includes steps or acts of: monitoring a plurality of requests for access to files; intercepting the requests; and analyzing metadata located in the file. If the metadata includes a directive entry, the method includes these additional steps: identifying information about any application requesting access to the file, including a sequence of function calls that preceded the file access request; and logging the information to generate an action trail of the application. A mechanism for monitoring file access includes the following: a file system configured for monitoring accesses to any file residing within it; an access control mechanism which can execute pre-defined actions when an unauthorized file access occurs; and a tool to specify the list of files to be monitored.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    None. 
       STATEMENT REGARDING FEDERALLY SPONSORED-RESEARCH OR DEVELOPMENT 
       [0002]    None. 
       INCORPORATION BY REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISC 
       [0003]    Not Applicable. 
       FIELD OF THE INVENTION 
       [0004]    The invention disclosed broadly relates to the field of computer operating system serviceability and more particularly relates to the field of monitoring and controlling file access to diagnose the cause of unexpected behavior by the operating system. 
       BACKGROUND OF THE INVENTION 
       [0005]    Operating system administrators often encounter maintenance issues that are caused by the unexpected actions of applications. For example, an application may change the permissions of a device file or modify a system configuration file that is used by multiple applications. The modifications in these files can cause other applications to fail. These incidents are difficult to diagnose because they occur randomly, and in most cases, it is difficult to identify the specific application that caused the error. 
         [0006]    There is a need for a method and mechanism to overcome the stated shortcomings of the known art. 
       SUMMARY OF THE INVENTION 
       [0007]    Briefly, according to an embodiment of the invention, a method for monitoring access to a file within a file system includes steps or acts of: monitoring all requests for access to files; intercepting all of the requests; and analyzing metadata located in the file. If the metadata includes a directive entry, the method includes these additional steps: identifying information about any application requesting access to the file, including a sequence of function calls that preceded the file access request; and logging the information to generate an action trail of the application. 
         [0008]    A mechanism for monitoring file access includes the following: a file system configured for monitoring accesses to any file residing within it; an access control mechanism which can execute pre-defined actions when an unauthorized file access occurs; and a tool to specify the list of files to be monitored. 
         [0009]    According to another embodiment of the present invention, a computer program product embodied on a computer readable medium includes code that, when executed, causes a computer to perform the following acts: monitor all requests for access to files; intercept all of the requests; and analyze metadata located in the file. Further, if the metadata includes a directive entry, the code further causes the computer to: identify information about any application requesting access to the file, including a sequence of function calls that preceded the file access request; and log the information to generate an action trail of the application. 
         [0010]    The method can be implemented either as machine executable instructions executed by a programmable information processing system or as hard coded logic in a specialized computing apparatus such as an application-specific integrated circuit (ASIC). 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    To describe the foregoing and other exemplary purposes, aspects, and advantages, we use the following detailed description of an exemplary embodiment of the invention with reference to the drawings, in which: 
           [0012]      FIG. 1  illustrates various components involved in the invention: user mode applications, kernel components (of which file-system is one), and the hard disks where the files may reside; 
           [0013]      FIG. 2  illustrates the sequence of actions taken by various components in the existing art when an application tries to access a file in a file-system; 
           [0014]      FIG. 3  illustrates the new sequence of actions taken by various components when an application tries to access a file in a file-system, according to an embodiment of the present invention; 
           [0015]      FIG. 4  illustrates the sequence of steps taken when a system administrator asks a file to be monitored, using the embodiment illustrated in  FIG. 3 ; 
           [0016]      FIG. 5  illustrates a new sequence of actions according to an alternative embodiment of the present invention; and 
           [0017]      FIG. 6  illustrates a sequence of actions for the monitor-file-access command, according to the alternative embodiment illustrated in  FIG. 5 . 
           [0018]    While the invention as claimed can be modified into alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the scope of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    We describe a method for monitoring file access. This method alerts a system administrator whenever an offending application accesses a file, and also provides information about the application. The objective is to enhance the serviceability of computer operating systems (i.e. reduce the unplanned outage time) by providing a synchronous, accurate, and very low overhead method to generate an action trail of the erroneous/offending application. This invention provides the ability to pinpoint the exact application and the specific operations within that application that caused the system or outage problem. 
         [0020]    According to an embodiment of the present invention, this is accomplished by intercepting a given type of access to a file and by identifying the details of the application that accessed that file, including the sequence of function calls which preceded the access to the file. The identification of the application and the function calls is done by walking the stack when the file modification/deletion event occurs. The interception of accesses to the file is accomplished by adding an ACL (Access Control List) entry associated with the file system object that directs the file system to record a log entry whenever a specific access is requested on the file. At a high level, the following steps describe a typical scenario where the mechanisms of our invention are applied: 
         [0021]    Referring now in specific detail to the drawings, and particularly  FIG. 1 , there is illustrated an exemplary embodiment of the present invention, wherein an operating system running on a multi-processor machine has kernel components that manage various hardware resources in the machine and provide abstractions of these resources to the applications  100 ,  101 , through  109 . The applications  100 ,  101 - 109  running in user mode use system calls  130  to utilize the kernel abstractions of the hardware resources.  FIG. 1  shows multiple applications ( 100  through  109 ) running in an operating system. The operating system&#39;s kernel typically contains several components such as a Virtual Memory Manager ( 110  VMM), a Scheduler ( 111 ), an I/O subsystem ( 112 ), a Logical File System ( 113 ), an Access Control Engine ( 114 ), and multiple physical file systems ( 115 , 116  . . . ), and other components. 
         [0022]    The applications  100 - 109  access the hardware resources managed by the OS kernel via system call interfaces  130 . The physical file systems store their file contents onto a hard disk  120 . Each file  121  has associated meta-data, of which the Access Control List (ACL)  122  is one type of meta-data. 
         [0023]      FIG. 2  illustrates an exemplary flowchart of file access control flow when an application  100  tries to modify a file  121 , according to the known art. In step  201 , application  100  opens the file  121  in write mode by invoking a system call open( ) which transfers control of execution from user mode into kernel mode. 
         [0024]    In step  202 , the open( ) system call implemented in the logical file system  113  identifies the physical file system  115  associated with the file  121 , and invokes the file-system operation provided by that physical file system  115  to perform the open to the file  121 . 
         [0025]    In step  203 , the physical file system  115  calls Access Control Engine  114  to verify that the user of the Application program  100  has permissions to write to the file  121 . In step  204 , the Access Control Engine  114  reads and analyzes file  121 &#39;s Access Control List (ACL)  122  to determine whether the user has permissions to write to the file  121 . 
         [0026]    In step  205 , the Access Control Engine  114  decides whether to allow the application  100  to write to the file  121  or not. If the access is allowed, in step  206 , the physical file system  115  successfully opens the file  121  for writing and returns a handle that uniquely identifies the opened file. If the access denied, in step  207 , the physical file system  115  returns an error to the application  100 . 
         [0027]    The format and content of the Access Control List (ACL)  122  varies with the different file system types and their implementations. In file systems that are compliant with the NFS (Network File System) Version 4 specification, the ACL format allows us to specify a directive known as an audit entry which can be used to invoke a specific action, such as writing a log record, whenever that entry is present. 
         [0028]      FIG. 3  illustrates the sequence of actions taken when an application tries to modify the contents of a file, according to an embodiment of the present invention. Steps  301 ,  302 , and  303  are similar to steps  201 ,  202 , and  203  in  FIG. 2 . The same explanation given above with respect to  FIG. 2  holds true in this case also. 
         [0029]    In step  304 , however, the ACL engine  114  analyzes the ACL  122  of the file  121  to check the operations allowed on this file  121  for the user of the application  100 . While analyzing the ACL  122 , if the ACL engine  114  finds any audit entry for the given user, it will record a log entry with information about the application and the user. 
         [0030]    This invention introduces a mechanism at this step to obtain the stack trace of the thread at this instance and write it as part of the log entry. In addition to the stack trace, the name of the command that created the process, the user name, group id, and the time stamp are also added to the log entry to accurately identify the application. This stack trace and other information will enable easy identification of an offending application when the system administrator later analyzes the log entries. Steps  305  through  308  of  FIG. 3  correspond to steps  204  through  207  of  FIG. 2 . 
         [0031]    The mechanism to identify the sequence of function calls (call-chain) made by the thread that accessed the given file can be implemented by walking through the chain of stack frames starting from the current stack frame. In each stack frame the return address is noted, and based on those return addresses, the functions involved in the call chain are identified. 
         [0032]      FIG. 4  illustrates how this invention can manipulate the command line tool: monitor_file_access. This tool is used to insert an audit entry into the ACL  122  of the file  121 , and will cause subsequent file accesses to be logged into a system log file (as explained in  FIG. 3 ). In step  401 , the system administrator issues the monitor_file_access command specifying the name of the file to be monitored. In step  402 , the monitor_file_access program will invoke a system call to insert the audit Access Control Entry (ACE) into the file  121 &#39;s ACL  122 . In step  403 , the system call identifies the exact file system containing the file  121  and invokes that file system&#39;s set_acl operation to add a new ACE. In step  404 , the file system&#39;s set_acl operation will invoke the ACL engine  114  to verify that the user has permissions to modify the ACL  122  and insert the new ACE. In step  405 , the ACL engine  114  performs those functions and adds a new ACE into the ACL  122  of the file  121 . 
         [0033]    Note that the usage of the ACL  122  as illustrated in this exemplary embodiment is only one implementation of this invention. This invention can be implemented even in file systems which do not support an NFS Audit entry in the Access Control Lists  122 , by maintaining a list of file names to be monitored for access within the kernel&#39;s Logical File System (LFS)  113  component. This list can be maintained at the system call layer, independent of the specific file system implementation.  FIGS. 5 and 6  illustrate the sequence of steps taken when the monitoring is implemented in the LFS layer. 
         [0034]    Referring to  FIGS. 5 and 6 , in step  501  the application opens a file  121  in write mode by calling the open( ) system call. In step  502 , the LFS layer, which implements the open( ) system call, checks its internal table to find if the file is being monitored for write access. The list of monitored files gets into the LFS&#39;s internal table when the system administrator issues the monitor_file_access command as illustrated in steps  601  through  603 . The LFS will call the Physical file system&#39;s open operation to perform the open function. If the open operation is successful, the Physical file system returns a handle to the LFS, which the LFS stores into its table and returns success to the application. 
         [0035]    Later, when the application issues a write( ) system call on file  121  in step  503 , the LFS will check its table in step  504 , and if a match is found for the file  121  a log entry is created with the stack trace and other diagnostic information about the process that issued the write( ) system call. In steps  505  and  506 , the physical file system performs the actual write operation to the file. 
         [0036]    When a system administrator identifies that a particular file is being randomly modified, he/she can use the monitor_file_access tool to add an entry to the file&#39;s ACL  122  such that all subsequent accesses to that file will be recorded into a predefined log. From then on, whenever an application requests access to that file, the mechanisms described above will create a log record containing information about the application name and the sequence of function calls. The system administrator can view the log to identify which application is causing maintenance issues, and can send the function call-chain to the application developer or application vendor to facilitate further diagnosis, or to provide a code fix to prevent future such problems. 
         [0037]    Using the mechanism as described in this disclosure, the system administrator requests the operating system to monitor these file[s] for all future undesirable modifications, and to provide the function call-chain and user information at the time of file modification. If no more undesirable modifications occur to these files, then the problem no longer exists. If the system error or problem occurs again, the mechanism provides sufficient information of the call-chain and calling process&#39; identification, so that future recurrence of the problem can be avoided. This avoidance of future problem occurrences can be achieved by any of the following methods: a) by changing the permissions of the file[s], or b) by blocking the offending process&#39; access, or c) by modifying the offending application&#39;s code. 
         [0038]    Therefore, while there have been described what are presently considered to be the preferred embodiments, it will be understood by those skilled in the art that other modifications can be made within the spirit of the invention. The above descriptions of embodiments are not intended to be exhaustive or limiting in scope. The embodiments, as described, were chosen in order to explain the principles of the invention, show its practical application, and enable those with ordinary skill in the art to understand how to make and use the invention. It should be understood that the invention is not limited to the embodiments described above, but rather should be interpreted within the full meaning and scope of the appended claims.