Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/10—File systems; File servers
  • G06F16/18—File system types
  • G06F16/188—Virtual file systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

• the present invention relates generally to computing devices, and more particularly, to managing file system usage for applications executing on computing devices.
• file system problems may be caused in less malicious ways, such as through programming errors made by the program developers .
• a program might overwrite another program's critical files with its own (possibly incompatible) version, which may lead to unpredictable results.
• Uninstaller programs might be used that fail to completely uninstall a program, leaving behind parts of the application that are no longer usable. And, faulty uninstallers are provided in some cases, making programs difficult to uninstall. When applications that are no longer needed are not uninstalled, system resources may be wasted.
• File system views are created for each application executed by a user, where this user- specific view comprises operating system files needed to run the application and file system changes made with this application for this user. Changes made to the file system during execution are allowed (in accordance with the user's permissions), but by default, those changes are not visible to other applications or to other users.
• a user or systems administrator may explicitly specify that particular applications have access to other views, where this access may comprise read-only access, copy-on-write access, and so forth.
• the access to other views may be allowed among applications executed by the same user, and/or may comprise allowing one or more of this user's file system views to be accessed by applications executed by one or more other users .
• file system views may be created for an application without regard to individual users, where that application's view is then used for all users who execute the application.
• Figs. 1 and 2 illustrate sample file system usage scenarios
• Fig. 3 illustrates stacking of application file system views
• Fig. 4 shows a sample graphical user interface ("GUI") display with which permissions to access file system views may be granted;
• GUI graphical user interface
• Fig. 5 illustrates using file copies in per-user, application-specific file system views
• Fig. 6 illustrates one manner in which metadata might be structured for storing information about the file copies from Fig. 5 and their usage in various file system views;
• Figs . 7 - 9 provide flowcharts depicting logic which may be used when implementing one or more embodiments of the present invention.
• Fig. 10 depicts a data processing system suitable for storing and/or executing program code.
• Embodiments of the present invention bring the advantages of virtual memory into the realm of file systems.
• virtual memory allows multiple applications to execute without the knowledge of other executing applications, while the collection of executing applications shares the same physical memory in a well-controlled manner.
• Virtual memory usage provides security and reliability that was impossible when using prior shared memory space techniques.
• the term "virtualized file system" is used herein to refer to multiple applications sharing a file system, each application having its own view of one or more files from the file system.
• each application is treated as a separate entity, per user, for every user that executes the application.
• the application is given a "fresh" view of the base file system (where this view of the "base” file system preferably includes the operating system files required for executing the application) .
• this view of the "base” file system preferably includes the operating system files required for executing the application.
• any changes made to the file system are allowed (in accordance with the user's permissions), but by default, those changes are not visible to other applications or to other users.
• this user-specific view shows only those file system changes that were made with this application for this user: by default, changes made by other users, and by this user when executing other applications, are not visible.
• one or more embodiments of the present invention enable a user to allow access to the user's view of the file system, created with regard to a particular application, by other applications.
• Each such other application accessing the file system view can be given different permissions to use the files in the view, if desired.
• the user may also grant permissions to other users to access a file system view.
• per-user security is still maintained.
• the user may allow access to a particular one of his or her views, granting read-only access to another user or perhaps by granting copy-on-write permission.
• the integrity of the user's files will be maintained: there is no risk of the other user altering the files within the original user's view.
• Techniques disclosed herein enable an installed application to be portable among systems that use the same operating system: by transferring the application's file system view (for example, by transferring a package comprising a collection of the system files and data files used/created by the application) from a first system to a second system, the second system is able to execute the application as if it was still executing on the first system, and equally, as if the previous executions of the application had taken place on the second system.
• transferring an installed application from a first system to a second system would normally require knowledge of each individual file used by the application on the first system, such that the proper set of files could then be located and transferred to the second system.
• An application can be completely uninstalled, using techniques disclosed herein, by removing its file system view; and, if multiple users have views of the application, an administrator may delete all the views. That is, all changes made by an application can be deleted by removing the view(s) containing the record of those changes. In addition, a user can determine which files have been changed by an application by examining the application's file system view.
• Figs. 1 - 2 illustrate sample file system usage scenarios. (In each case, the scenarios are depicted from a single user's perspective.)
• OS operating system
• the files in the system typically include a number of core operating system files, illustrated in Fig. 1 at reference number 110. A number of patches to the operating system may also be present. These files are represented at reference number 111.
• the file access permissions of the operating system are shown in column 120. As indicated in Fig. 1 by the graphic at reference number 121, the operating system itself has full access to the core OS files and patches.
• a file system view may be created for the core operating system files 110 and the patches 111; or, separate file system views may be created for 110 and 111, if desired.
• reference numbers 112, 113, and 114 of Fig. 1 indicate that each of the 3 applications uses some set of files.
• each application executed by a user will create a separate view for its files, as noted above.
• individual file system views are preferably created for each of 112, 113, and 114 (where each view also preferably includes the operating system files/patches used by the respective application) .
• the sets of files 112 - 114 are non-overlapping (i.e., the applications have no files in common, other than their usage of the core OS files 110 and patches 111) .
• Application 1 is a human resources application used for a corporation's employees
• Application 2 is an accounts payable application used for paying the corporation's suppliers
• Application 3 is an online shopping application.
• the operating system is given full access to the files used by each application (including any files newly-created by the applications) .
• the graphic at reference number 122 indicates that OS 120 has full access to the files in Application l's file system view
• the graphics at reference numbers 123 and 124 indicate that OS 120 has full access to the files in the file system views for Application 2 and Application 3, respectively.
• Application 1 has copy-on-write permission to the operating system's core files 110 and patches 111. See the graphic at
• COW Copy-on-write access, or “COW”, as that term is used herein, refers to using a base version of a file until determining that an update is required, and then making a copy of the file and applying the update to the copy. The copy will be reflected in the application's file system view, as updated. By default, such changes are not then viewable outside the view.
• the file access permissions of Applications 2 and 3 are shown in columns 140 and 150, respectively.
• Applications 2 and 3 both have copy-on-write permission to the operating system's core files and patches. See the graphics at 141 and 151.
• Both Application 2 and Application 3 have full access to their own files; see the graphics at 142 and 152.
• none of the applications access files from the other applications' file system views.
• FIG. 2 a second file system usage scenario is illustrated.
• the operating system 120 has full access to the core OS files and patches 110, 111, as shown at 121 of Fig. 2.
• the operating system also has full access to the files of the applications (i.e., to the file system views created for the applications), which in this case are represented by reference numbers 112, 213, and 114; see the graphics at reference numbers 122, 223, and 124 of Fig. 2.
• Application 1 and Application 3 in this second scenario are the same applications discussed above, namely a human resources application used for a corporation's employees and an online shopping application.
• an application named "Application 4" replaces Application 2, where Application 4 is an e-mail application usable by the corporation's employees.
• Application 1 is responsible for maintaining a current list of the corporation's employees, and that this list is consulted by Application 4 (e.g., to ensure that only authorized employees can access the corporation's e-mail resources) .
• the files used by Applications 1 and 4 have an overlap.
• Application 4 has copy-on-write access to the file system view(s) for core operating system files 110 and patches 111 (see reference number 241) , while having full access to a file system view comprising its own files 213 (see reference number 243) as well as copy-on-write access to (at least some of) the files of Application 1 (see reference number 242) .
• Application 4 will make a copy of applicable ones of the files from the file system view created for Application l's files, store that copy in the local file system view for Application 4, and make any updates to that local copy.
• any changes that Application 4 makes to its local copy are not viewable to Application 1 (unless the user or administrator explicitly allows such access) .
• An application's file system view may be considered a "stacked" view that generally comprises the file system view the application was installed "on top of”, plus any file system alterations made by the application. From this perspective, file system views for other applications may be stacked "underneath" a particular application's file system view. This stacking is illustrated using Fig. 3, as will now be described.
• a base operating system is installed, and creates a view "V(O)". See reference number 310 of Fig. 3.
• a word processor is also installed, and is executing under control of that operating system. The word processor may therefore be considered as installed on top of the operating system, and therefore the word processor's file system view is "on top of" the operating system's file system view.
• the word processor's file system view is referred to as "V(I)", shown at 320.
• An e-mail program is also installed on top of the operating system and therefore its file system view is stacked on top of the operating system's file system view. The e-mail program's file system view is shown as "V(2)"; see reference number 330.
• FIG. 3 shows the spreadsheet program's file system view, "V (3)", as being stacked on top of the file system view V(I) of the word processor. See reference number 340. (This stacking may be done, for example, by a user or administrator after installation of one or more applications . )
• the spreadsheet program can access (using appropriate permissions) all files installed or created by the word processor, but not vice versa, because the word processor's file system view V(I) is part of the underlying stack of the spreadsheet program's file system view V (3).
• all of the applications can access files installed by the operating system in its underlying file system view V(O). If files of the operating system need to be patched, for example to address security vulnerabilities, the patches can be made to file system view V(O) — assuming appropriate authentication is established for updating those files — and (assuming explicit user/administrator permission for accessing the view) all applications installed on top of view V(O) will then benefit from the security patches.
• Files in the present invention's virtualized file system can be created, overwritten, altered, etc.
• all changes are captured by a file system processing layer; this layer then associates the changes with the user and the application making the change.
• the association is recorded in a persistent store such as a relational database.
• the collection of data to be stored is referred to herein as "metadata".
• metadata For subsequent executions of a particular application by the user, the changes made to the file system during previous executions will be visible, but in general (e.g., without explicit access permission to the file system view) , other applications will not see those changes. Instead, the other applications will see their own view of the files in the file system.
• ⁇ If two applications executed by a user need to interoperate and thereby access the other's files, their file system views can be merged, such that all changes made by one application are seen by the other application. Or, permissions can be granted to allow one application to access files of another application's file system view.
• the e-mail program in Fig. 3 may be given read-only permission to the word processor's file system view V(I). This enables documents generated by the word processor to be e-mailed using the e-mail application, for example .
• Fig. 4 shows a sample GUI display 400 with which permissions to access file system views may be granted.
• This GUI illustrates availability of user-specific views for 2 users (see reference number 410, stating “By User") ; see reference numbers 411 and 419, where the users are identified as “pierceju” and "pkdo”.
• Fig. 4 also illustrates an alternative approach that may be supported by one or more embodiments of the present invention, where file system views are not only provided per user, per application (as has been discussed) : in this alternative approach, file system views may also be established per application, without regard to which user is executing the application. This latter approach is shown at reference number 420, referring to the file system views that have been created "By Application". This alternative approach may be particularly beneficial where all users should share the same version of the files in a particular file system view.
• An embodiment that allows views per user, per application as well as views per application may, for example, provide a configuration interface through which a choice of these approaches can be made .
• the view for user "pierceju” 411 is expanded, in this illustration. See, generally, reference number 412.
• this user has application file system views named “Operating System 1", “Patches”, “Notepad”, and "E-mail Client”, and in this example, each of these views can be further expanded to show logical components of the views that are available.
• the E-mail Client view at 413 has been expanded to show 2 components "Core Files” 414 and "Created Files” 415.
• Graphical highlighting is provided around the text "E-mail Client” at 413 to indicate that this application's file system view has been selected (e.g., using a mouse pointer). See also 401, where the selected application's name is presented in the descriptive information for window 400.
• the panes 440, 450, and 460 show the file system access permissions within the views created for user 411' s execution of the E-mail Client application. As shown in pane 440, in this example, direct control (full access) is provided over files in the "Created Files" and "Core Files" components of the E-mail Client application view.
• the E-mail Client application can perform operations including read, write, delete, and so forth on those files.
• Pane 450 shows that copy-on-write access has been specified for files in the "Patches”, “Operating System 1", and “Core System” views.
• Pane 460 shows that read-only access has been specified for files in the "Created Files" component of the "Notepad” application view.
• the user may specify file access permissions through a GUI such as that shown in Fig. 4, for example by dragging and dropping graphic representations of file system components from pane 430 to panes 440 - 460 or by dragging and dropping graphic representations among the panes 440 - 460.
• Fig. 5 provides an illustration of using file copies in file system views, where a base version exists for each of a first file "ABC” 500 and a second file “DEF” 540. Copies of file ABC have been made for 3 different file system views, in this example.
• a user "pierceju” has a copy 510 in a view for a word processor ("WP") application.
• WP word processor
• a user "pkdo” has a first copy 520 in a view for the word processor and a second copy 530 in a view for a spreadsheet application.
• any changes made to these copies 510 - 530 are not viewable among users or among applications, unless an administrator or the user for whom the copy was made grants permission for accessing the view containing that copy.
• Copies may be made of file DEF 540 in one or more application views as well, although this has not been illustrated.
• the view that includes the copy 510 might also include a copy of file DEF, such that the word processor executed by user "pierceju" can make updates to file DEF.
• Fig. 6 provides one example to illustrate how metadata might be structured for storing information about the file copies from Fig. 5 and their usage in various file system views.
• a tabular form is shown in Fig. 6, although other data structures may be used.
• Metadata 600 in this example comprises entries for each file 610, 620, and for each file, provides an identification 630 of the "owner" of a particular view of the file (e.g., specifying that this is the base version, or identifying the user and application on whose behalf a copy was created) ; the location 640 of the copy used in that view; and, as applicable, access permissions 650 for the view.
• an entry 660 is provided for the base version of file ABC (illustrated at reference number 500 in Fig.
• Permissions column 650 indicates, in this example, that copy-on-write permission applies to the view created for user "pierceju" when using the application "WP".
• Metadata 600 may be provided in metadata 600 without deviating from the scope of the present invention, although this has not been illustrated.
• an alternative organization may be used for the metadata. For example, instead of organizing the metadata by file, as shown in Fig. 6, one alternative approach that may be used is to organize the metadata by application within user, such that all file copies that have been created for a particular user are stored together, grouped according to the application for which the copies were created.
• an operating system application programming interface (“API") is provided through which file access requests are made, and calls to routines of this API invoke operations of a file system layer that provides the virtualized file system disclosed herein.
• API application programming interface
• metadata for the calling application and user is consulted and the invocation is processed accordingly (as will be discussed in more detail with reference to Figs. 7 - 9) .
• use of the virtualized file system is transparent to the application developer, who simply codes the application to invoke the API without regard to how the underlying file system is implemented.
• Such an application might, for example, include code to ask the user whether the user wishes this application's file system view to be accessible to other selected applications (such as a set of applications created by a common vendor) .
• FIG. 7 - 9 flowcharts are provided that depict logic which may be used when implementing embodiments of the present invention. Each of these figures will now be discussed.
• Block 700 when a write request is received for a particular file, the requesting user and application are determined (Block 700) .
• the metadata for this file is consulted (Block 710) to determine whether a copy has been created in a view corresponding to the requesting user and application.
• Block 710 as well as corresponding logic of the remaining flowcharts, may be adapted to other approaches for the metadata organization. For example, rather than accessing a relational database using the file name as a key, according to the structure illustrated in Fig. 6, a key might alternatively be comprised of an identifier of the requesting user and application.
• the test at Block 720 checks to see if a copy of this file already exists for the requesting user and application, according to the metadata. If not, then processing continues at Block 730, where a copy of the file is made and added to the file system view that corresponds to this user executing this application.
• the copy may be made from the base version of the file, the location of which may be determined (for example) from the metadata. Alternatively, when file system views are stacked (as discussed with reference to Fig. 3) , the copy may be made from the top- most view that both underlies the current view and contains a view of this particular file.
• Block 740 updates the metadata to include an entry for this newly-created copy.
• Control reaches Block 750 when the test in Block 720 has a positive result (i.e., a copy of the file already exists in the view for this user executing this application), and following execution of Block 740.
• the write request is performed using the copy in the view for the requesting user and application. Processing then exits from Fig. 7.
• Fig. 7 has not illustrated details of copy-on-write processing. It will be obvious to one of skill in the art how the illustrated logic can be adapted, for example to delay making the copy at Block 730 until determining that the write request will, in fact, be made to cause an alteration to the data in the file. (Furthermore, embodiments of the present invention may use write processing that does not include a copy-on-write optimization.) Furthermore, Fig. 7 has not illustrated details of permission checking, e.g., to determine whether the write request is being attempted for a file having read-only permission. It will be obvious, once the teachings of the present invention are known, how the logic depicted in Fig. 7 (as well as in Figs. 8 and 9) can be augmented for such checking.
• Fig. 8 illustrates processing for a read request that is received for a particular file.
• the requesting user and application are determined (Block 800) .
• the metadata for this file is consulted (Block 810) to determine whether a copy has been created in a file system view corresponding to the requesting user and application.
• the test at Block 820 checks to see if a copy of this file already exists for the requesting user and application, according to the metadata. If not, then processing continues at Block 830, where the read request is carried out using the base version of the file. (When views are stacked, as discussed with reference to Fig. 3, a "precedence" approach may be used where the read request reads a file copy from the top-most view that both underlies the current view and contains a view of this particular file, rather than using the base version.) Otherwise, when the test at Block 820 has a positive result, then the read is carried out at Block 840 using the copy of the file from the current file system view (that is, the file system view for the requesting user and application) . Processing then exits from Fig. 8.
• Fig. 9 illustrates processing for a delete file request that is received for a particular file.
• the requesting user and application are determined (Block 900) .
• the metadata for this file is consulted (Block 910) to determine whether a copy has been created in a file system view corresponding to the requesting user and application.
• the test at Block 920 checks to see if a copy of this file exists in the current view for the requesting user and application, according to the metadata. If not, then the delete file operation will not be performed, and processing exits from Fig. 9. (A message may be generated, if desired, indicating that the request will not be carried out.) Otherwise, Block 930 removes the copy of the file from the current file system view. Processing then exits from Fig. 9.
• Processing requests to delete an individual data item from a file may be implemented in a manner similar to the write operation illustrated in Fig. 8. That is, if a copy of the file does not yet exist in the file system view for the requesting user and application, then a copy is made for that view, and the deletion of data is then carried out using that file copy. Otherwise, the deletion is made to the copy that already exists in the file system view. (If the current view does not have a copy of the file, but a copy exists in an underlying, stacked view, then the stacked copy is preferably used when creating the copy for the current view. )
• Requests to open and close files may be handled using logic similar to that of Fig. 8, substituting "open” or “close” for "read”, respectively (and separate flowcharts illustrating these details are not deemed necessary to a full understanding of the present invention) .
• the metadata is preferably checked to determine whether a copy exists in the current file system view. If not, then the base version (or an underlying stacked copy, as applicable) is preferably opened or closed, depending upon the requested action; otherwise, the copy in the current file system view is opened or closed.
• Block 700 can be adapted to obtain the identifier of the requesting application, and Block 710 can be adapted to check the metadata associated with this application.
• Block 710 can be adapted to check the metadata associated with this application.
• separate API calls are provided for this approach, and logic adapted from the examples shown in Figs. 7 - 9 is used for supporting these separate API calls.
• One or more embodiments of the present invention may be provided that support installation of more than one operating system on a particular computing system, including installation of heterogeneous operating systems on a single computing system.
• Each operating system is preferably provided with its own file system view, using techniques disclosed herein. (See, for example, reference numbers 421 and 422 of Fig. 4, where views for "Operating System 1" and “Operating System 2", respectively, are represented in the GUI 400.)
• a user may then be allowed to select execution under a particular one of the installed operating systems. Because each operating system's files are stored in separate file system views, collisions and incompatibilities among them are avoided. Permission to access files in other views may be enabled among the file system views of the operating systems, if desired (e.g., by specifying permissions using GUI 400) .
• the present invention may be provided as methods, systems, and/or computer program products comprising computer-readable program code. Accordingly, the present invention may take the form of an entirely hardware/firmware embodiment. An embodiment combining software and hardware/firmware aspects might be used alternatively. Or, components of the present invention may be provided in a software embodiment.
• components of the invention may take the form of a computer program product accessible from computer-usable or computer-readable media providing program code for use by, or in connection with, a computer or any instruction execution system.
• a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport a program for use by, or in connection with, the instruction execution system, apparatus, or device.
• the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
• Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, removable computer diskette, random access memory (“RAM”) , read-only memory (“ROM”) , rigid magnetic disk, and optical disk.
• Current example of optical disks include compact disk with read-only memory (“CD-ROM”) , compact disk with read/write (“CD-R/W”) , and DVD.
• a data processing system 1000 suitable for storing and/or executing program code includes at least one processor 1012 coupled directly or indirectly to memory elements through a system bus 1014.
• the memory elements can include local memory 1028 employed during actual execution of the program code, bulk storage 1030, and cache memories (not shown) which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
• I/O devices including but not limited to keyboards 1018, displays 1024, pointing devices 1020, other interface devices 1022, etc.
• I/O controllers or adapters 1016, 1026
• network adapters may be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
• Modems, cable modem attachments, wireless adapters, and Ethernet cards are just a few of the currently- available types of network adapters.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Hardware Design (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• General Health & Medical Sciences (AREA)
• Bioethics (AREA)
• Health & Medical Sciences (AREA)
• Data Mining & Analysis (AREA)
• Storage Device Security (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (1)

Applications Claiming Priority (2)

Publications (1)

Family

ID=37056610

Family Applications (1)

Country Status (4)

Cited By (4)

Families Citing this family (23)

Citations (5)

Family Cites Families (15)

• 2005
  • 2005-06-15 US US11/153,846 patent/US8732220B2/en not_active Expired - Fee Related
• 2006
  • 2006-05-30 JP JP2008516269A patent/JP4931255B2/ja not_active Expired - Fee Related
  • 2006-05-30 CN CNA2006800170487A patent/CN101176096A/zh active Pending
  • 2006-05-30 WO PCT/EP2006/062725 patent/WO2006134023A1/en not_active Ceased

Patent Citations (5)

Also Published As

Similar Documents

Legal Events