Secure access-based enumeration of a junction or mount point on a clustered server

Embodiments described herein provide a technique for securely responding to an enumeration request of a data container stored at a location referenced by a junction or mount point within a share served by a storage system. To that end, the technique applies access permissions of the data container at the referenced location instead of permissions that may reside at the junction or mount point. Upon determining that the permissions are insufficient to allow access to the data container, the technique ensures that a descriptor of the junction or mount point is not included in a response to the enumeration request.

BACKGROUND

1. Technical Field

The present invention relates to storage systems and, more particularly, to access-based enumeration of shared resources in such systems.

2. Background Information

A storage system typically includes one or more storage devices, such as disks, into which information may be entered, and from which information may be obtained, as desired. The storage system may also include a storage operating system that may implement a high-level module, such as a file system, to logically organize the information stored on the disks as a hierarchical structure of data containers, such as files and directories. In addition, the storage system may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access the data containers stored on the system. Each client may request the services of the storage system by issuing messages (in the form of packets) to the system using storage (e.g., file-based) access protocols, such as the conventional Common Internet File System (CIFS) protocol.

To facilitate client access to the information stored on the storage system, the storage operating system typically exports units of storage, e.g., (CIFS) shares. As used herein, a share is equivalent to a mount point or shared storage resource, such as a folder or directory that stores information about files or other directories served by the system. A client access feature of the storage system may be to provide an ordered listing or “enumeration” of data containers within a share, or a portion of the share, served by the storage system. Typically, a client issues an enumeration request on behalf of a user to solicit enumeration of the data containers within a directory of the share. In response, the storage system returns a list of descriptors for those data containers included in the directory specified in the enumeration request. The response typically contains only those descriptors for which the user making the enumeration request has sufficient access permission.

Conventionally, access permission is determined per export unit, e.g., per share, as a property of the whole share. Consequently, a user with permission to access the share may have sufficient permission to view a descriptor of any file or folder served by the share, even if that user has insufficient permission to access the files or folders themselves. Security problems may arise for enumeration requests when descriptors of files and folders are visible to a user who doesn't have sufficient permission to access those files and folders. For example, the name of a file or folder may describe confidential information, such as the name of a customer or a new product under development. To remedy this problem, access permission may be determined using access-based enumeration (ABE), which lists descriptors of enumerated data containers based on a user's access permission to those data containers. A user without sufficient permission to access a data container is deemed to have insufficient permission to access a descriptor of the data container.

A further security problem arises with access-based enumeration of junctions or mount points. As used herein, a junction or mount point is an identifier that redirects access to a data container to a storage location referenced by the junction rather than the location containing the junction or mount point; however, permission to access the data container may appropriately reside at the reference location. For example, the administrator may alter the access permission of the data container at the reference location leaving any permission stored at the location of the junction or mount point unaltered. Failure to apply the appropriate user access permission of the data container at the reference location, in response to an enumeration request, may result in a security breach in which a descriptor of a junction or mount point is provided to a user with insufficient permission to access the contents of the data container referenced by that junction or mount point. The problem may be compounded when further indirection is employed, such as when a junction references a data container at another storage location and that data container includes another junction that references yet another data container at yet another storage location, and so on.

Accordingly, there remains a need for a method and system for secure access-based enumeration of junctions or mount points on a server.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Embodiments described herein provide a technique for securely responding to an enumeration request of a data container stored at a location referenced by a junction or mount point within a share served by a storage system. To that end, the technique applies access permissions of the data container at the referenced location instead of permissions that may reside at the junction or mount point. Upon determining that the permissions are insufficient to allow access to the data container, the technique ensures that a descriptor of the junction or mount point is not included in a response to the enumeration request.

Although implementation of the secure enumeration response technique may be useful within any storage system, the embodiments described herein are illustratively implemented within a clustered storage system. In one embodiment, a protocol layer in a storage system of the cluster may be modified to receive a client enumeration request for the share, e.g., a directory, using a file-based protocol. In response, the protocol layer may initiate performance of a file system operation to obtain a list of descriptors of data containers, including junctions and mount points, within the directory. This list of descriptors may then be pruned or amended using access-based enumeration of junction or mount point type entries within the list, prior to returning the amended list in response to the client enumeration request. In accordance with the technique, the access-based enumeration for each junction or mount point type entry in the descriptor list is performed by making an access-based enumeration of the data container referenced by the junction or mount point. Where the client has insufficient permission to access the referenced data container, the descriptor of the respective junction or mount point is removed from the list of descriptors.

Illustratively, for each junction descriptor within the list, the protocol layer employs a junction table to obtain a file handle to a data container referenced by the junction descriptor. For each obtained file handle, the module creates a lookup request that includes the file handle for the data container referenced by the junction. Each lookup request is sent to a file system executing on the storage system of the cluster that is configured to serve the respective data container. The lookup request may also include user credentials of the client making the enumeration request and an access-based enumeration (ABE) flag instructing the file system to perform an access permission check on the data container for the given user credential. In response to the lookup request, the file system compares the data container access permission to the user credential by applying an ABE permission mask. The ABE permission mask defines a set of permissions that allow access to the data container. A result from the comparison indicating whether the client has permission to access to the data container is returned by the file system to the protocol layer, in response to the lookup request. When the returned lookup request indicates an access denied, the protocol layer removes the descriptor (i.e., associated by indirection with the data container) for the junction or mount point from the list of descriptors intended as a response to the client enumeration request. Thus, for each returned lookup request indicating an access denied, the descriptor list is amended to remove the junction descriptor associated with the respective junction or mount point. The module then returns the amended list of descriptors to the client in the response to the user enumeration request.

DESCRIPTION

A. Cluster Environment

FIG. 1is a schematic block diagram of a plurality of nodes200a,binterconnected as a cluster100and configured to provide storage service relating to the organization of information on storage devices. The nodes200comprise various functional components that cooperate to provide a distributed storage system architecture of the cluster100. To that end, each node200is generally organized as a network element (N-module310) and a disk element (D-module350). The N-module310includes functionality that enables the node200to connect to clients180over a connection system140, which may be a computer network, and with other N-modules over a cluster interconnect150and alternatively over connection system140, while each D-module350connects to one or more storage devices, such as disks130of a disk array120. The nodes200are interconnected by the cluster interconnect150which, in the illustrative embodiment, may be embodied as a Gigabit Ethernet switch or the like. An exemplary distributed file system architecture is generally described in U.S. Pat. No. 6,671,773 titled METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS, by M. Kazar et al. issued Dec. 30, 2003. It should be noted that while there is shown an equal number of N and D-modules in the illustrative cluster100, there may be differing numbers of N and/or D-modules in accordance with various embodiments of the present invention. For example, there may be a plurality of N-modules and/or D-modules interconnected in a cluster configuration100that does not reflect a one-to-one correspondence between the N and D-modules. As such, the description of a node200comprising one N-module and one D-module should be taken as illustrative only.

The clients180may be general-purpose computers configured to interact with the node200in accordance with a client/server model of information delivery. That is, each client may request the services of the node, and the node may return the results of the services requested by the client180, by exchanging packets over the connection system140. The client may issue packets including file-based access protocols, such as the Common Internet File System (CIFS) protocol or Network File System (NFS) protocol, over the Transmission Control Protocol/Internet Protocol (TCP/IP) when accessing information in the form of files and directories.

B. Storage System Node

FIG. 2is a schematic block diagram of a node200that is illustratively embodied as a storage system comprising a plurality of processors222a,b, a memory224, a network adapter225, a cluster access adapter226, a storage adapter228and local storage230interconnected by a system bus221. The local storage230comprises one or more storage devices, such as disks, utilized by the node to locally store configuration information, e.g., a copy of a storage operating system300. The cluster access adapter226comprises a plurality of ports adapted to couple the node200to other nodes of the cluster100. Each node200amay communicate with another node200bby exchanging discrete frames or packets of data according to pre-defined protocols, such as TCP/IP. In the illustrative embodiment, Ethernet is used as the clustering protocol and interconnect media, although it will be apparent to those skilled in the art that other types of protocols and interconnects may be utilized within the cluster architecture described herein. In alternate embodiments where the N-modules and D-modules are implemented on separate storage systems or computers, the cluster access adapter226is utilized by the N/D-module for communicating with other N/D-modules in the cluster100.

Each node200is illustratively embodied as a dual processor storage system executing storage operating system300that preferably implements a high-level module, such as a file system, to logically organize the information as a hierarchical structure of named data containers, such as directories, files and special files, e.g., on the disks. However, it will be apparent to those of ordinary skill in the art that the node200may alternatively comprise a single or more than two processor system. Illustratively, one processor222aexecutes the functions of the N-module310on the node, while the other processor222bexecutes the functions of the D-module350; however, in an alternate embodiment, the N/D-modules may be implemented as pieces of code within a single operating system process that may execute dynamically across one or more processors222a,b.

The memory224includes a plurality of storage locations addressable by the processors222a,band/or adapters225,226,228for storing software programs (e.g., processes and/or services) and data structures (e.g., enumeration list223) associated with the embodiments described herein. The processors and adapters may, in turn, include processing elements and/or logic circuitry configured to execute the software programs and manipulate the data structures. Storage operating system300, portions of which are typically resident in the memory224and executed by the processors222a,b, functionally organizes the node200by, inter alia, invoking operations in support of the software processes and/or services executing on the node. It will be apparent to those skilled in the art that other processing and memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the embodiments described herein.

The network adapter225comprises a plurality of ports adapted to couple the node200to one or more clients180over a connection system140, which may include point-to-point links, wide area networks, wireless networks, and virtual private networks implemented over a public network (Internet) or a shared local area network. The network adapter225thus may comprise the mechanical, electrical and signaling circuitry needed to connect the node200to the network. Illustratively, the connection system140may be embodied as an Ethernet network or a Fibre Channel (FC) network. Each client180may communicate with the node200over network140by exchanging discrete frames or packets of data according to pre-defined protocols, such as TCP/IP.

The storage adapter228cooperates with the storage operating system300executing on the node200to access information requested by the clients. The information may be stored on any type of attached array of writable storage device media such as optical, magneto-optical, magnetic tape, bubble memory, storage class memory, flash memory, electronic random access memory, micro-electro mechanical and any other similar media adapted to store information, including data and parity information. However, as illustratively described herein, the information is preferably stored on the disks130of array120. The storage adapter228comprises a plurality of ports having input/output (I/O) interface circuitry that couples to the disks130over an I/O interconnect arrangement, such as a conventional high-performance FC link topology.

Storage of information on each disk array120may be implemented as storage “volumes” that illustratively comprise a collection of physical storage disks130cooperating to define an overall logical arrangement of a volume block number (vbn) space on the volume(s). Each logical volume is generally, although not necessarily, associated with its own file system. Alternatively, a plurality of arrays120may be aggregated into a larger logical volume. Aggregates and logical volumes are disclosed and described in U.S. Pat. No. 7,409,494 titled EXTENSION OF WRITE ANYWHERE FILE SYSTEM LAYOUT to John K. Edwards et al. and issued on Aug. 5, 2008. Briefly, an aggregate includes one or more groups of disks, such as Redundant Array of Independent (or Inexpensive) Disks (RAID) groups, that are apportioned by the storage operating system300into one or more virtual volumes of the storage system. Each such virtual volume has its own logical properties, utilizes algorithms of the storage operating system implementation and serves storage objects, such as files with different file types and formats. An example of a file type of a storage object is a volume that may be exported as a file system, e.g., to a client180. The disks within a logical volume/file system are typically organized as one or more groups, wherein each group may be operated as a Redundant Array of Independent (or Inexpensive) Disks (RAID). An illustrative example of a RAID implementation is a RAID-4 level implementation, although it should be understood that other types and levels of RAID implementations or data redundancy techniques may be used in accordance with the inventive principles described herein.

It should be noted that in another alternate embodiment of the invention, the processing elements of adapters225,226,228may be configured to offload some or all of the packet processing and storage access operations, respectively, from processor222, to thereby increase the performance of the storage service provided by the node. It is expressly contemplated that the various processes, architectures and procedures described herein can be implemented in hardware, firmware, software, or combinations thereof.

C. Storage Operating System

To facilitate access to the disks130, the storage operating system300illustratively implements a write-anywhere file system that cooperates with one or more virtualization modules to “virtualize” the storage space provided by disks130. The file system logically organizes the information as a hierarchical structure of named data containers, such as directories and files on the disks. Each “on-disk” file may be implemented as set of disk blocks configured to store information, such as data, whereas the directory may be implemented as a specially formatted file in which names and links to other files and directories are stored.

In the illustrative embodiment, the storage operating system is preferably the NetApp® Data ONTAP® operating system available from Netapp, Inc., Sunnyvale, Calif. that implements a Write Anywhere File Layout (WAFL®) file system. However, it is expressly contemplated that any appropriate storage operating system may be enhanced for use in accordance with the principles described herein. As such, where the term “WAFL” is employed, it should be taken broadly to refer to any storage operating system that is otherwise adaptable to the teachings of the disclosure herein.

FIG. 3is a schematic block diagram of the storage operating system300that may be advantageously used with one or more embodiments described herein. The storage operating system300, portions of which are typically resident in memory224and executed by the processors222a,bfunctionally organizes the node200by, inter alia, invoking storage operations in support of the storage service implemented by the node.

The storage operating system may comprise a series of software layers organized to form an integrated network protocol stack or, more generally, a multi-protocol engine325that provides data paths for clients180to access information stored on the node200using block and file access protocols, e.g. iSCSI and NFS protocols. The multi-protocol engine includes a media access layer312of network drivers (e.g., gigabit Ethernet drivers) that interfaces to network protocol layers, such as the IP layer314and its supporting transport mechanisms, the TCP layer316and the User Datagram Protocol (UDP) layer315. A protocol layer provides multi-protocol file access and, to that end, illustratively includes support for the NFS protocol320and the CIFS protocol322.

In addition, the storage operating system may include a series of software layers organized to form a storage server365that provides data paths for accessing information stored on the disks130of the node200. To that end, the storage server365may include a file system module360in cooperating relation with a RAID system module380and a disk driver system module390. The RAID system380manages the storage and retrieval of information to and from the volumes/disks in accordance with I/O operations, while the disk driver system390implements a disk access protocol such as, e.g., the SCSI protocol.

The file system360is illustratively a message-based system that provides logical volume management capabilities for use in access to the information stored on the storage devices, such as disks. The file system360illustratively implements WAFL having an on-disk format representation that is block-based using, e.g., 4 kilobyte (kB) blocks and using index nodes (“inodes”) to identify data containers (such as files or directories) and file attributes (such as creation time, access permissions, size and block location). Illustratively, access permissions are stored in an access control list including one or more access control entries each associated with security identifier (SID) as commonly used in a CIFS environment. In addition, access permissions may have a user identifier (UID) and/or a group identifier (GID), such as typically used by NFS. Access permissions are described in further detail in commonly owned U.S. Pat. No. 7,668,881 titled SYSTEM AND METHOD FOR ASSOCIATING NIS ATTRIBUTES WITH CIFS CLIENTS to Hoffmann et al., issued Feb. 23, 2010.

The file system360may use files to store meta-data describing the layout of its on-disk file system; these meta-data files include, among others, an inode file. A data container handle, i.e., an identifier that includes an inode number, is used to retrieve an inode from disk.

The protocol layers, e.g., the NFS layer320and CIFS layer322, of the N-module310function as protocol servers that translate file-based requests from clients into CF protocol messages used for communication with the D-module350. That is, the N-module servers convert the incoming data access requests into file system primitive operations (commands) that are embedded within CF messages by the CF interface module340a,bfor transmission, e.g., over cluster interconnect150, to the D-modules350of the cluster100. Notably, the CF interface modules340a,bcooperate to provide a single file system image across all D-modules in the cluster100. Thus, any network port, e.g., an interface on network adaptor225, of an N-module310that receives a client request can access any data container within the single file system image located on any D-module350of the cluster100. The CF protocol is illustratively a generic file and/or block-based protocol that comprises a collection of methods/functions constituting a CF application programming interface (API). Examples of such an agnostic CF protocol are the SpinFS and SpinNP protocols available from Netapp, Inc. details of which are described in the aforementioned U.S. Pat. No. 6,671,773, titled METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS to M. Kazar et al.

In addition to distributing the volumes served by the cluster100among the nodes200of the cluster100, an administrator may relocate the volumes or data containers stored on the volumes among any of the nodes200in the cluster. However, it is desirable to allow a client180to still access the relocated data container using a data container handle associated with the prior location. In order to ensure that relocation of the data container is transparent to the client, the administrator may employ a redirection identifier that indicates to the file system360that the requested data container is not stored at the original storage location identified by the data container handle. The administrator may manage redirection identifiers by issuing commands at a management station195. For example, the administrator can enter a command to create a redirection identifier for a particular volume either through a graphical user interface (GUI)196or through a command line interface (CLI), or the like. In an alternative embodiment, one or more of the clients180may act as the management station195.

An example of a redirection identifier is a junction that is associated with a storage location and that indicates that data is not stored at an originally-used location but is available at another storage location. Essentially, the junction provides a level of indirection between a storage system and a client180accessing a data container served by the cluster100.

To facilitate client180access to the information stored in the cluster, the node typically exports units of storage, e.g., (CIFS) shares. As used herein, a share is equivalent to a mount point or shared storage resource, such as a folder or directory that stores information about files or other directories served by the cluster. For example, a client may access information in the directory by mounting the share and issuing a CIFS protocol access request that specifies a uniform naming convention (UNC) path to the share. The UNC path or pathname is an aspect of a storage networking environment that defines a way for a client to refer to a unit of storage on the cluster. The UNC pathname specifies resource names on a network. For example, a UNC pathname may comprise a server name, a share (directory) name, and a path descriptor that collectively reference a unit of storage or share. Resolution of the server name is usually required to access the share, i.e., the client typically requires knowledge of the specific physical location (i.e., the identity) of the server exporting the share. Thus, an additional form of redirection identifier is a mount point to a share on another volume.

FIG. 4a. is a schematic block diagram illustrating an example of a namespace400that may be advantageously used with the present invention. A junction acts as mount point for another volume “vol/w”, so that the volumes “/vol/v” and “/vol/w” form a unified namespace400accessible by the client180. Depending on the access permissions, various users may view differently the same portions of the namespace as illustrated, for example, inFIGS. 4b-d. Notably, a namespace may be viewed when the storage server365has access-based enumeration (ABE) activated (turned-on) or deactivated (turned-off).

ABE permission to view a portion of a namespace400, e.g. a hierarchy of data containers, may be determined from an access permission for each data container beneath a directory rooting that portion of the namespace hierarchy. For, example,FIG. 4b. illustrates a user (“user1”) view of the namespace400from the directory (“dir v2”) when ABE is turned-off. The “user1” is permitted to view the contents of junction “v4” (i.e., “root /vol/w” referenced by the “junction v4”) because permission402b(“user1:RW”) allows it. Here, file “Foo” with access permission402a(“user1:RW; user2:R”) is also visible to “user1.” However, with ABE turned-on, as illustrated inFIG. 4c., “user1” cannot view “v4” because the access permission402c(“user2:RW”) of the referenced data container (“root /vol/w”) has no access permission for “user1.”

Even further indirection may be employed, such as when the namespace400contains yet more junctions in the hierarchy, which may visible only to some users. For example,FIG. 4dillustrates namespace400as viewed from “user2” with ABE turned-on where a junction “w1” with access permission402d(“user3:R”) is nevertheless visible to “user2” because the access permission402e(“user1:RW; user2:R”) of the data container (“vol/x”) referenced by the junction “w1” allows “user2” to view “w1.” In this example, “user3” may view “w1” only when ABE is turned-off, in which case access permission402d(“user3:R”) is applied instead of access permission402e. Notably, in this case (ABE turned-off), “user2” cannot view “w1.”

Junctions are described in further detail in commonly owned U.S. Pat. No. 8,312,046 titled SYSTEM AND METHOD FOR ENABLING A DATA CONTAINER TO APPEAR IN A PLURALITY OF LOCATIONS IN A SUPER-NAMESPACE to Eisler et al., which issued on Nov. 12, 2012 (the contents of which are incorporated herein by reference in entirety).

An other example of a redirection identifier that may provide a level of indirection, i.e., with respect to a data container served by a storage server, is a symbolic link. A symbolic link (“symlink”) is a data structure that, instead of representing the name of data container, such as a file or directory, provides a path descriptor (such as a UNC path name) to that data container. Some file system implementations, such as the Microsoft NTFS file system, permit a symlink path descriptor to reference a data container located on a volume different from that containing the symlink, which are commonly called wide symlinks (Microsoft also refers to these type of symlinks as “junctions”). A technique for utilizing wide symlinks to provide a further level of indirection in this manner for the storage server365is described in commonly owned U.S. Pat. No. 6,968,345 titled TECHNIQUE TO ENABLE SUPPORT FOR SYMBOLIC LINK ACCESS BY WINDOWS CLIENTS to Muhlestein, which issued on Nov. 22, 2005.

FIG. 5is a sequence diagram illustrating a flow of information in response to an enumeration request, e.g., a directory enumeration request, in accordance with one or more embodiments herein. A client180issues an enumeration request using file access protocol, e.g., CIFS or NFS, to cluster100(e.g., directed to a node200in the cluster100over the connection system140). Illustratively, a CIFS enumeration request includes a TRANS2_FIND_FIRST request or TRANS2_FIND_NEXT request for Server Message Block (SMB) version 1 and SMB2_COM_QUERY_DIRECTORY request for SMB version 2 (detailed in the “Common Internet File System (CIFS) Technical Reference, version 1” available from the Storage Networking Industry Association). An example of an NFS enumeration request is READDIR (detailed in Internet Engineering Task Force Request for Comment 1813 and 3530 available from http://www.ietf.org).

An enumeration request500typically includes a directory502and user credential501. User credentials may include a SID for a CIFS enumeration request or a UID and/or GID for an NFS enumeration request. The appropriate protocol layer of the N-module310, e.g., CIFS320, receives the enumeration request500for further processing. An enumerate module321issues a read directory (READDIR)504request processed by the file system READDIR module362. The READDIR request504may also include an indicator, e.g., a USE_ABE503flag, instructing the file system360to perform ABE enumeration when processing the request. The file system360returns a READDIR RESPONSE506having an enumerated list of descriptors corresponding to data containers within the directory502. The response506may include descriptors for redirection identifiers, e.g., junctions or mount points or wide symlinks, but not descriptors for data containers referenced by those redirection identifiers. The list of descriptors is buffered in memory224as an enumerated list223, illustratively embodied as a list or an array data structure.

Each redirection identifier descriptor in the enumerated list223has a data container that it references, i.e., a volume reference509. The enumerate module321examines each descriptor entry in the enumeration list223and for each redirection identifier (e.g., junction, mount point or wide symlink) issues a JUNCTION LOCATE REQUEST508having the respective volume reference509to the file system360so as to obtain a handle to the data container referenced by the redirection identifier. The file system module LOCATE364responds with the handle contained in a JUNCTION LOCATE RESPONSE510. The protocol layer, e.g., CIFS322, then issues a LOOKUP REQUEST512, again to the file system360. The LOOKUP REQUEST512has the handle511, a user credential501(received from the client180) and a permissions mask, ABE_mask513. The file system module LOOKUP514processes this request by performing an access check on the data container for the handle511, i.e. the data container referenced by the indirection identifier. Alternatively, a REDIRECTION PROCESS368may be used to redirect the LOOKUP REQUEST512via the cluster interconnect150to another node200servicing the data container for the handle511. The file system360returns an “access denied” response when the user credential501has insufficient permission to access the data container associated with the handle511. For each “access denied”, e.g., illustratively embodied as an integer identified as ACCESS DENIED, received by the protocol layer, i.e., the enumerate module321, in response to the LOOKUP REQUEST512, the descriptor associated the indirection identifier referencing the data container associated with the handle511, is removed from the enumeration list223. Once all the indirection identifier descriptors in the READDIR RESPONSE506are processed, the contents of the amended enumeration list223are returned to the client180in response to the enumeration request500.

The ABE_mask513illustratively includes a bit-mapped mask of permissions sufficient to satisfy an access-based enumeration of a data container for which access-based enumeration is sought. Illustratively, for Windows NT the ABE_mask513includes a bit map logical OR of special permissions SYNCHRONIZE, LIST_DIRECTORY, READ_EA, READ_ATTRIBUTES, and READ_CONTROL.

F. Protocol Stack

FIG. 6is a flow chart detailing steps of a procedure600performed by a protocol layer, e.g., enumerate module321, in accordance with one or more embodiments described herein. The procedure begins at step601and continues to step602where the enumeration request500is received by the enumerate module321from the client180directed to an exported share by the cluster100. At step604, the enumerate module321sends a read directory request504to the file system360. Illustratively, the read directory request504may also include an indicator, e.g., a USE_ABE flag503, instructing that an access-based enumeration be performed. In alternative embodiments, the send request may be a function call or a system call. At step606, the enumerate module321receives enumerated descriptor entries from the file system360. These entries are illustratively saved in memory224as enumeration list223at step608.

At step610, a determination is made (e.g., by the enumerate module321) as to whether an ABE flag for the share is set. If the ABE flag is not set, i.e., access-based enumeration is turned-off, then the contents of the enumeration list223are returned in response to the enumeration request500at step626and the procedure completes. If the ABE flag is set for the share (step610), then each enumerated descriptor entry is examined in turn. At step612, a determination is made (e.g., by the enumerate module321) as to whether the enumerated descriptor entry is a junction or mount point (or wide symlink) type. If not, the procedure returns to step612to examine a next entry. However, if the enumerated descriptor entry is a junction or mount point type (or wide symlink), then steps614through622are performed.

At step614a LOCATE REQUEST508is sent to the file system360for the data container referenced in the descriptor entry, e.g., the junction volume reference509. Thereafter, at step616, a junction handle511is received. At step618, a LOOKUP REQUEST512is sent to the file system360to perform an access check. A result of the access check is received (step620), and if the result is ACCESS DENIED then the descriptor entry associated with the junction handle511is removed from the enumerated list223(step624). Once all the descriptor entries have been examined, the contents of the enumerated list223are returned to the client180in response to the enumeration request500at step626.

G. File System

FIG. 7is a flow chart detailing steps of procedure700for reading directory entries performed by module READDIR362in accordance with one or more embodiments described herein. The procedure begins at step701and continues to step702where directory descriptor entries are loaded, e.g., for directory502. If the ABE flag is not set for the share (step704), i.e., access-based enumeration is turned-off, then the entries are returned as a response at step718and the procedure completes. If the ABE flag is set for the share (step704), then descriptor entries in a response are nulled, e.g., zeroed or null link list, at step706. Steps708through714are then performed for each descriptor entry in the directory to determine whether the respective descriptor is added to a response. If an enumerated descriptor entry is a junction or mount point (or wide symlink) at step708, then steps710through714are performed.

At step710the access permission, e.g., an access control list (ACL), for the data container referenced by the descriptor entry is obtained. An access check is performed based on the user credential501, e.g., UID/GID or SID, and the ABE_mask513at step712. Illustratively, this access check is performed with a bit-mask logical AND operation using the ABE_mask513and one or more portions of the user credential501. In other embodiments a comparison operation may be performed. In still other embodiments, the access permission for the data container may include an ACL having multiple entries wherein is access checked, e.g., iteratively by entry, with the user credential501.

If the result of the access check is not ACCESS DENIED (step714) then the descriptor entry is added, e.g. accumulated, to the response at step716. Once all the descriptor entries have been examined, the accumulated response is returned at step718and the procedure completes.

FIG. 8is a flow chart detailing steps of procedure800for looking-up referenced data containers performed by module LOOKUP366in accordance with one or more embodiments described herein. The procedure begins at step801.

At step802the access permission, e.g., ACL, for the data container referenced by the descriptor entry is obtained. An access check is performed based on the user credential501, e.g., UID/GID or SID, and the ABE_mask513at step804. This access check is illustratively performed with a bit mask AND operation of the ABE_mask513with one or more portions of the user credential501. In another embodiment, the access permission for the data container may include an access control list having multiple entries each of which is access checked with the user credential501. In a further embodiment, steps710and712of procedure700are identical to steps802and804respectively of procedure800, e.g., the READDIR module362and the LOOKUP module366may share a subroutine.

If the result of the access check is ACCESS DENIED (step806), then ACCESS DENIED is returned at step810and the procedure completes; otherwise OK, e.g., illustratively embodied as an integer having a value different from ACCESS DENIED, is returned at step808and the procedure completes.

H. Other Embodiments

The foregoing description has been directed to particular embodiments of this invention. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. Specifically, it should be noted that the principles of the present invention may be implemented in non-distributed file systems. Furthermore, while this description has been written in terms of N and D-blades, the teachings of the present invention are equally suitable to systems where the functionality of the N- and D-blades are implemented in a single system. Alternately, the functions of the N and D-blades may be distributed among any number of separate systems wherein each system performs one or more of the functions.

As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a computer to perform a storage function that manages data access and may, in the case of a node200, implement data access semantics of a general purpose operating system. The storage operating system can also be implemented as a microkernel, an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.

Additionally, the procedures, processes and/or modules described herein may be implemented in hardware, software, embodied as a computer-readable medium having program instructions, firmware, or a combination thereof. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the invention.