Patent Application
20090049047
In file systems, securable objects, such as documents and folders, may be used to store data. Information about the stored data, which may be referred to as metadata, may be associated with the securable object. Metadata may be associated directly with a securable object as part of a securable object data structure (e.g., as part of a master file table or similar data structure), it may be associated indirectly with a securable object as part of an independent data structure (e.g., as a secondary file data stream, an extended attribute, etc.), or otherwise stored (e.g., within a database, within an XML document, etc.).
When a system developer wants to add a new type of metadata to a file, modifying the securable object data structure may be undesirable due to programming complexity, compatibility problems, or other considerations. Modifying an independent data structure or data store may overcome these limitations, but may introduce performance constraints, loss of functionality, loss of the metadata when the securable object is copied or moved, and may cause other problems.
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
A computer-implemented system and method for storing custom metadata in a custom access control entry of a securable object. An exemplary method includes determining the custom metadata to be stored (e.g., information relating to the securable object that is inexpressible using a native file system application programming interface, information relating to remote domain permission data, information to support a custom feature of an application, etc.). The system may identify a custom access control entry (ACE) type corresponding to the custom metadata. In one embodiment, the custom ACE type is not a member of a set of ACE types directly interpretable by a native security subsystem to manage permissions for the securable object. The system may additionally store the custom ACE type and the custom metadata in a custom ACE, which may be added to the access control list of the securable object. The securable object may then be saved to the file system (e.g., to an NTFS file system).
Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings.
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
Turning to the objects depicted in
The native domain may include a collection of native trustee accounts 120. These trustee accounts 120 may include user accounts 122, group accounts 124, machine accounts 126, and/or other types of accounts. The trustee accounts 120 may be used to manage authentication and authorization within a native domain, including permissions within the native file system 110. In one embodiment, permissions stored in the native file system 110 correspond to objects within the collection of trustee accounts 120 (e.g., a conventional ACE for a securable object will have a SID corresponding to a SID of one of the trustee accounts). The trustee accounts may be part of and/or work in conjunction with the security subsystem. The security subsystem may be responsible for a variety of security operations, including, for example, enforcing access rules defined by the set of standard access control entries within a discretionary access control list. It may additionally be responsible for auditing attempts to access the securable object based on standard access control entries within a system access control list.
Turning to
The access control list 200 typically includes a plurality of conventional access control entries 202, 204, also referred to as conventional ACEs. Each conventional ACE 202, 204 may have a conventional ACE type (e.g., an ACE type that may be used by a native security subsystem in managing permissions within a native domain, including allow, deny, and audit ACE types). Each conventional ACE also may include a second data field configured to store a security identifier that corresponds to a trustee account within the domain. For example, the second data field may be configured to receive a security identifier (SID) corresponding to a trustee account (e.g., a user account, a group account, a machine account, etc) within the native domain. The conventional ACEs 202, 204 may also include a third data field containing data representing an access mask that, in combination with the first data field (e.g., ACE type) and the second data field (e.g., SID), determines a permission for a trustee for the securable object.
In addition to the conventional ACEs 202, 204, an access control list 200 may include custom ACEs 206, 208 having custom ACE types. Custom ACEs 206, 208 also have the first field of data (e.g., the ACE type), but the data within the custom ACE type field is not within the set of ACE types used by a security subsystem to manage permissions for a securable object. The custom ACE types may be determined by application developers, operating system developers, and/or other entities in order to support new functionality and/or provide additional information that may be inexpressible using a native file system API.
Exemplary functionality implemented by custom ACEs and referred to with custom ACE types may include remote domain metadata storage (e.g., “sticky bit” information in a file system that does not include “sticky bit” information within its API, storing remote domain permissions directly with a file as described with respect to
In addition to the ACE type field having the custom ACE type data, custom ACEs may have a custom metadata field (e.g., a fourth data field). Custom metadata may be described as metadata that does not correspond to conventional ACE metadata. In one embodiment, the custom ACE type and custom metadata, individually or in combination, do not include information interpretable by a native security subsystem. In one example, custom metadata does not include a native SID, a native access mask, and/or native inheritance information. In another example, a custom ACE added to a discretionary access control list (DACL) and/or system access control list (SACL) of a securable object does not affect native permissions relating to the object. The native permissions may be unaffected because the custom ACE does not have a SID corresponding to the SID of any trustee account, the custom ACE type does not correspond to an ACE type that is managed by a security subsystem, and/or for other reasons.
The size of the custom ACEs may be uniform or different from each other and from conventional ACEs, depending on the purpose of and/or data in the custom ACE. The meaning of the data within a particular custom metadata field may be dependent upon the ACE type. Custom metadata may be stored as plain text, hashed, encrypted, a combination thereof, or using other techniques.
Turning to
Identifying 306 a custom ACE type corresponding to the custom metadata may involve identifying a custom ACE type that is not a member of a set of ACE types used by the security subsystem to manage permissions for the securable object (e.g., ACE types corresponding to set of non-extensible ACE types used by the native security subsystem such as access allowed, access denied, and system audit). For example, custom ACE types may include custom ACE types that identify metadata corresponding to remote domain metadata storage (in which the remote domain has an operating system different than the native operating system), remote domain permission enforcement, enhanced native domain functionality, and/or other functionality. The custom ACE types may be determined by an application developer either before or after a native operating system is released, whereas the set of ACE types used by the security subsystem may be determined by the native operating system developer prior to the release of the operating system.
Storing 308 the custom ACE type and the custom metadata in a custom ACE may involve invoking a method or procedure on a file system to create an ACE having the custom ACE type and custom metadata. The created custom ACE may not include information relating to a set of native security information, the set including a security identifier, an access mask, and a set of inheritance information. The system may then add 310 the custom ACE to the access control list of the securable object and save 312 the securable object with the custom ACE having the custom metadata to the file system.
In addition to storing custom metadata in a custom ACE, custom metadata may also be read from a custom ACE stored as part of an ACL in a file system. One method of reading custom metadata from a custom ACE is depicted in
A variety of techniques may be used to actually implement the method of
Regarding the particular elements depicted in
The custom ACE may be converted 508 to the remote domain permission data. This conversion may involve reading the custom ACE as described above with respect to
Reading 606 the remote domain permission data may involve accessing the remote permission data received at 604. This permission data may have, for example, a format including a remote owner unique identifier (UID), a remote group identifier (GID), and user permission bits, group permission bits, and other permission bits. Additionally or alternatively, remote permission data may include “sticky bit” information for folders (e.g., to identify whether a user other than an owner of an included document may delete the document) or other information.
Storing 608 the remote domain permission data in a custom ACE may, for example, implement the elements described with respect to
A subsequent communication from a remote domain may initiate an export process. Although the export algorithm described above with respect to
Turning to the particular elements, receiving 612 a request to export the document may include receiving a request for the document and an identifier of a requestor (user, group, and/or, machine account, etc.). The requestor identifier may be part of message (e.g., as content delivered in a payload of a message received from a remote domain), as part of a session identifier, or otherwise transmitted from the remote domain. Upon receiving 612 the request, the native file system may grant 614 permission to access the document. It is understood that this element does not grant access to export the document from the native domain, but instead grants access to inspect the requested document (e.g., to evaluate the ACL of the document). The granting 614 element may be adjusted to suit a particular operating environment (e.g., it may be eliminated or modified if the export functionality is performed by a driver, system, or subsystem operating in kernel mode).
The custom ACE may be converted 616 to the remote domain permission data. This conversion may involve reading the custom ACE as described above with respect to
The computer system may include a memory device 710, such as random access memory, a processor 720, such as a microprocessor, a network interface 330, such as a network interface card, an Input/Output communication port 750, such as a USB port, and a system bus 740 that interconnects the components of the computer system 700. The network interface may enable communication with a remote computer system (not shown). Additionally, the computer system 700 may include non-volatile memory 760 having computer readable data including a file system 762 having an access control list with custom access control entries. The non-volatile memory 760 may also include native trustee accounts 764. During program execution, data and instructions may be transferred between the non-volatile memory 760 to memory 710.
Volatile memory 760 and memory 710 are both examples of computer readable storage media. By way of example, and not limitation, computer readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer system 700.
Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like. Furthermore, although the context for the disclosed system and method are for custom metadata stored in and read from custom access control entries, the system and method may operate outside the custom access control entry context, such as application programming interfaces for file systems other than or in addition to NTFS (e.g., file systems for other types of operating systems).
