US20100235396A1 - Distributed File System Access - Google Patents
Distributed File System Access Download PDFInfo
- Publication number
- US20100235396A1 US20100235396A1 US12/402,764 US40276409A US2010235396A1 US 20100235396 A1 US20100235396 A1 US 20100235396A1 US 40276409 A US40276409 A US 40276409A US 2010235396 A1 US2010235396 A1 US 2010235396A1
- Authority
- US
- United States
- Prior art keywords
- access
- client
- user
- trusted
- filesystem
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
Definitions
- DFSs Distributed Filesystems
- a DFS is a network filesystem where a single filesystem can be distributed across several physical computing devices, and the computing devices can have direct access to a part of the entire filesystem.
- the DFS generally includes facilities for transparent replication and fault tolerance. That is, when a limited number of nodes in a filesystem go offline, the system continues to work without any data loss. Therefore, the DFS has become a very popular choice for local area networks (LAN) in organizations, corporations, and so on.
- LAN local area networks
- file access permissions are granted on three levels (i.e., owner, group, and other users). Each level can have its own permissions, and users can be granted access based on their level's access permissions.
- each file has an associated owner identification (ID) (i.e., the ID of the user who created the filesystem object), and group ID (i.e., the owner can be part of one or more groups).
- ID owner identification
- group ID i.e., the owner can be part of one or more groups.
- the present file access permissions reduce chances of security breach (to a large extent) for local filesystems, where multiple users can access files from the same machine, but in distributed filesystems, the file access permissions can introduce vulnerabilities.
- DFSs multiple users present on different computing devices can access a single filesystem object. Therefore, the file access permissions create certain problems in DFSs. These problems occur because in DFSs it is not necessary for user IDs to be unique on all the computing devices in the system. For example, two users (such as user A and user B) can have the same user ID (such as ID 1000), on different client devices. So, when user A attempts to access a file created by user B, user A will be allowed access to the file (based on the owner access permissions of the file), even though user A did not create the file. The system permits this action as the file access permissions simply recognize user IDs, and since both the users have the same user ID, both user A and user B are recognized as owners of the file. Therefore, an authentic user can easily be faked, which can cause serious security threats.
- ID 1000 such as ID 1000
- Some methods centralize the user IDs and group IDs in a central repository, which ensures that no two users have the same user ID.
- Each time a user requests access to a file object the user's credentials are verifyed against the repository.
- a user can still fake a user ID on the new installed client device.
- the entire system can crash if the central repository crashes.
- Embodiments of the invention are directed to methods and systems for providing access to filesystem objects in a distributed filesystem.
- a method for providing access in a Distributed Filesystem includes the steps of retrieving a user identification (ID) and a client ID of a requesting user and determining whether the client ID corresponds to a trusted client or a non-trusted client.
- the method further includes obtaining extended access permissions of a filesystem object and allowing access to the filesystem object based on the user ID, the client ID, and the extended access permissions of the filesystem object.
- the extended access permissions of the object can include a T bit that indicates whether the filesystem object was created on a trusted client, and an L bit that indicates whether the requesting user is allowed to access the filesystem object from a non-trusted client.
- a system for providing access in a DFS includes a memory and a processing device that are operatively coupled to retrieve a user ID and a client ID of a requesting user and determine whether the client ID corresponds to a trusted client or a non-trusted client. Moreover, the system obtains extended access permissions of a filesystem object, where the extended access permissions can include a T bit that indicates whether the filesystem object was created on a trusted client, and an L bit that indicates whether the requesting user is allowed to access the filesystem object from a non-trusted client. Further, the system allows access to the filesystem object based on the user ID, client ID and the extended access permissions of the filesystem object.
- FIG. 1 is a block diagram illustrating an exemplary distributed filesystem (DFS) in which the claimed invention may operate.
- DFS distributed filesystem
- FIG. 2 illustrates a block diagram of a virtual filesystem of some embodiments of the claimed invention.
- FIG. 3 illustrates exemplary extended access permissions according to some embodiments of the claimed invention.
- FIG. 4 is a diagram illustrating exemplary scenarios in which a user can be allowed or denied access to a filesystem object.
- FIG. 5 is a flowchart of a method for providing access to filesystem objects in a distributed filesystem.
- FIG. 6 is a flowchart of a method for determining access to a filesystem object in a distributed filesystem.
- An embodiment of the claimed invention describes a method for providing access in a distributed filesystem (DFS).
- the method allows authentic users to access filesystem objects. Further, the method allows users to access filesystem objects from authentic client devices.
- Another embodiment of the claimed invention uses a combination of user identification (ID) and client ID, to recognize unique users. Further, the concept of trusted computing is utilized in the claimed invention.
- filesystem access permissions can be extended in order to enhance the security of objects in the distributed filesystem.
- FIG. 1 is a block diagram illustrating an exemplary Distributed FileSystem (DFS) 100 in which the claimed invention may operate.
- the DFS 100 includes a network 102 that interconnects one or more filesystem server computing devices 104 -A, 104 -B (filesystem servers 104 ), one or more client computing devices 106 -A, 106 -B, 106 -C, and 106 -D (clients 106 ), and a central repository 108 .
- one or more users 110 -A, 110 -B, 110 -C, and 110 -D can access objects stored on the filesystem servers 104 , from the clients 106 , through the network 102 .
- Filesystem objects can include files, directories, folders, documents, and other similar objects commonly stored on digital media.
- various filesystems can be distributed across the filesystem servers 104 , which can be located in different geographical locations, but can logically be mapped under a root DFS folder. Therefore, the users 110 are not required to know the exact location of the filesystem servers 104 . Further, the DFS 100 can include facilities for transparent replication and fault tolerance so that when a limited number of the filesystem servers 104 go offline, the DFS 100 continues to work without any data loss.
- the network 102 may be any wired or wireless network known in the art.
- the network can be a local area network (LAN), a metropolitan area network (MAN), the Internet, and so on.
- the network 102 is a private network, such as a company network, connecting a plurality of office PCs, various servers, and other computing-based devices spread throughout several countries.
- the network 102 includes a home network with a limited number of PCs belonging to a single family, connected over a WLAN.
- the network 102 can connect a limited number of clients in a small business. It will be appreciated that the type of network will not limit the scope of the invention, and any known network configuration can be used to implement the DFS 100 .
- the DFS 100 can function on any operating system known in the art, such as the IBM AIX® operating system, the Solaris Filesystem, the Linux filesystem, the Microsoft Windows® operating system, the MAC operating system, and so on. Embodiments of the claimed invention are described with reference to a UNIX operating system, though any operating system known in the art can be utilized instead.
- the filesystem servers 104 and the clients 106 can be equipped with a memory, a processing device, input/output ports, networking ports, and so on.
- the filesystem server 104 -A is depicted with a memory 112 and a processing device 114 .
- the processing device 114 may include microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
- the processing device 114 is configured to fetch and execute computer-readable instructions stored in the memory 112 .
- the memory 112 can include any computer-readable medium known in the art including, for example, volatile memory (e.g., RAM) and/or non-volatile memory (e.g., flash, etc.).
- the memory 112 and the processing device 114 can have any suitable physical implementation and they can be operatively coupled depending on the particular device implementation. These components can be adapted, arranged, configured, and designed to perform methods in accordance with the teachings herein, for example, as illustratively described by reference to FIGS. 2-6 . It will be apparent to people of ordinary skill in art that each of the clients 106 and the filesystem servers 104 can be equipped with a memory and a processing device.
- embodiments of the claimed invention restrict access to users on unauthorized clients (i.e. clients not recognized by the DFS 100 ), and allows access to authorized users on unauthorized clients.
- all the clients 106 are divided into two groups, namely trusted clients and non-trusted clients, according to principles of trusted computing.
- Trusted Computing is a technology developed and promoted by the Trusted Computing Group. With Trusted Computing, the clients 106 consistently behave in specific ways enforced by hardware and software. Enforcing trusted behavior is achieved by loading the hardware with a unique ID and a unique master key and denying knowledge and control of the master key to even the owner of a client. Trusted Computing not only secures the hardware for the owner, but against the owner as well, thereby prohibiting users from faking authorized users. Many techniques are known in the art for implementing Trusted Computing, such as Network Filesystem (NFS). Network Information Service (NIS). Lightweight Directory Access Protocol (LDAP), and so on. Any of the known techniques can be used to implement TC.
- NFS Network Filesystem
- NIS Network Information Service
- LDAP Lightweight Directory Access Protocol
- NIS can be utilized.
- the client IDs are stored in a central repository, such as the central repository 108 .
- Each client has a list of user IDs it can support. Since the client IDs are centrally stored, the NIS ensures that no two clients have the same user IDs, thereby ensuring unique user IDs.
- a new client installed in the network 102 that tries to access the filesystem servers 104 is treated as a non-trusted client, as NIS is not sure whether the client has unique user IDs.
- NIS configures the client and the user IDs on the client are in agreement with the user IDs on the trusted clients, the client can be upgraded to the trusted client group.
- FIG. 1 illustrates trusted clients 116 and non-trusted clients 118 .
- the trusted clients 116 include clients 106 -A, 106 -B, and 106 -C, and the non-trusted clients 118 include clients 106 -D, 106 -E.
- the trusted clients 116 and the non-trusted clients 118 can be included in a list of clients stored in the memory 112 of the filesystem servers 104 .
- the list of clients can be stored in the central repository 108 .
- new clients in the network 102 can be directly added to the non-trusted clients 118 .
- the clients can be upgraded to the trusted clients 116 .
- the NIS verifies the user's client ID against the list of clients. If the user's client ID is not present in the list of clients, the NIS does not allow access to the user 110 . In case the client ID is present in the list of clients, the filesystem server 104 confirms if the user 110 has presented the correct user ID. Based on the confirmation, the user ID is checked against, the access permissions of the filesystem object.
- the claimed invention ensures that the users 110 can have unique identification and clients that are not part of the unique identification scheme can be the non-trusted clients 118 .
- the separation of the trusted and non-trusted clients allows the filesystem servers 104 to allow authentic users on the trusted clients 116 to access the filesystem server 104 and at the same time deny access to fake users on the non-trusted clients 118 .
- users can be identified by using a combination of user ID and client ID, where the client ID corresponds to the client that the user typically operates on.
- the combination of the user ID and the client ID can be in any form, such as numerical values, alphanumeric, values, user names, MAC addresses, user personal information, and so on.
- any unique ID such as a numeric value, an alphanumeric value, etc., can be considered as a user ID.
- access to filesystem objects is based on the user ID, the client ID, and the access permissions of a filesystem object. Since, the users are defined not only by their user IDs, but also their respective locations (if the user is on a trusted or a non-trusted client), the conventional access permissions of the objects have to be modified in order to provide different access permissions based on the location of the user. To this end, embodiments of the claimed invention add some new bits to the access permissions of the current filesystems and overload the existing access permission bits. An explanation of extended access permissions is provided in conjunction with FIG. 3 .
- a user ID and at least one group ID can be used to identify a user.
- users in one group can be classified under one group ID.
- an organization can have various teams, such as a financial team, a human resources team, an IT team and so on.
- the members of the financial team can be grouped under a financial group ID
- the human resources team can be grouped under a human resources group ID, and so on.
- the managers of the teams can be organized under an executive group ID.
- An administrator or a root user can manage the group IDs.
- all filesystem objects include the user ID of the owner that created the filesystem object and the group ID of the group to which the owner belongs.
- Conventional access permissions can be permissions such as read, write, and execute permissions for different levels of users, such as owner of the object, group member, or any other user.
- UNIX typically assigns 9-bit access permissions, which can be depicted as three octal digits. Each octal digit represents permissions for the owner, the group member, or any other user respectively. The first octal digit represents the access permissions for the owner of the object, the next octal digit represents the access allowed for members of a group to which the owner belongs, and the last octal digit represents access permissions for any other user. Further, each binary bit of the octal digit can represent individual permissions, such as read, write, and execute permissions.
- the first bit indicates read permission
- the second bit indicates write permission
- the third bit indicates execute permission. If the bit value is 1, the permission is activated, else, the permission is blocked.
- an octal digit 7 has a binary value of 111, which indicates that the user has read, write, and execute permissions for the filesystem object.
- An authorized user such as the owner of the object or an administrator, typically assigns the access permissions.
- the access permissions can be preset for processes, or an environment, so all the objects created in that process or environment will automatically have the access permissions assigned to that process or environment.
- An authorized user can modify the access permissions of an object at any time after its creation.
- the conventional access permissions are stored in a metadata file called inode, which stores basic information about a regular file, directory, or other filesystem object.
- Each filesystem object can have an inode and an inode number (often referred to as an “i-number” or “inode”) that can identify the inode in the filesystem and where it resides.
- inodes store information about filesystem objects, such as the user ID of the owner, and the group ID, access permissions (read, write, execute permissions) and type of object. Further, the inode number indexes a table of inodes in a known location on the device; from the inode number, the kernel can access the contents of the inode and the contents of the filesystem object. Conventionally, the kernel searches a directory looking for a particular filename and then converts the filename to the correct corresponding inode number.
- the DFS 100 has a number of filesystems, and in certain embodiments, the filesystems can be of different types, such as the Solaris® filesystem, the Linux® filesystem, the Windows® filesystems, the Mac OS filesystems, the UNIX® filesystems, and so on.
- Each of the filesystem servers 104 can have their own manner of storing the metadata about the filesystem objects.
- a virtual filesystem (VFS) abstraction layer can be present on top of the filesystem servers 104 in the DFS 100 .
- VFS virtual filesystem
- FIG. 2 depicts a VFS 202 and its relation with the various filesystem servers 104 .
- the VFS 202 can allow the clients 106 to access different types of the filesystem servers 104 in a uniform manner. Moreover, the VFS 202 can, for example, be used to access local and network servers transparently without the clients 106 noticing the difference. In one implementation.
- the VFS 202 bridges the differences in various filesystems, so that the clients 106 can access objects on the filesystems without having to know the type of filesystem.
- the VFS 202 uses a data structure called a vnode 204 .
- All file manipulations can be done with the vnode 204 , which includes public and private data.
- the public data fields in each vnode 204 either include data that is manipulated only by the VFS 202 layer or data about the filesystem object that does not change over the life of the filesystem object, such as the file type.
- the private data fields in the vnode 204 point to data that is dependent on the filesystem, such as the inode table of the filesystem.
- the vnode 204 is depicted with inode table entries of the filesystem servers 104 .
- the vnode 204 of the filesystem can point to inode numbers of the filesystem objects of a particular filesystem server 104 . Therefore, in the DFS 100 , the access permissions of objects can be accessed through the vnode and/or the inode of the filesystem object. Further, the access permissions field in the inode is typically a 16-bit field. Presently, 9 of these 16 bits are used to define the conventional access permissions of the filesystem object, while 3 bits are used for special purpose security, which leaves four unused bits in the 16-bit access permission field.
- FIG. 3 illustrates exemplary extended access permissions 300 according to embodiments of the claimed invention.
- the exemplary extended access permissions 300 include 11 bits as opposed to the conventional 9-bit access permissions explained above.
- Embodiments of the claimed invention utilize two of the four unused bits in the access permissions field.
- the first 9 bits of the extended access permissions 300 (that can be represented as three octal digits) are used to indicate owner mode bits 302 , group on a trusted client mode bits 304 , and other (everyone else) mode bits 306 .
- embodiments of the claimed invention alter the definition of the mode bits.
- the second octal digit represented access permissions for group members, but according to the claimed invention, the second octal digit indicates access permissions for the group members accessing the object from the trusted clients 116 .
- the third octal digit 306 indicates permissions for other, rather than for others as done previously.
- the other mode bits 306 can be checked for owners on the non-trusted clients 118 , group members on the non-trusted clients 118 , or other users.
- the tenth and eleventh bits can be a T bit 308 and an L bit 310 that are introduced in an embodiment of the claimed invention.
- the T bit 308 indicates whether the filesystem object was created on the trusted clients 116 or on the non-trusted clients 118 .
- An enabled status (e.g., bit value 1) on the T bit 308 indicates that the filesystem object was created on the trusted clients 116
- a disabled status (e.g., bit value 0) on the T bit 308 indicates that the filesystem object was created on the non-trusted clients 118 .
- the processing device can automatically set the T bit 308 , once the object has been created. Further, in cases when the owner is allowed access to the object and the owner modifies the object from the trusted clients 116 , the T bit 308 can be automatically enabled, if previously disabled.
- the L bit 310 indicates whether the owner of an object is allowed access to the object, wherein the owner is a user on a non-trusted client 118 .
- an enabled L bit 310 indicates that the owner is allowed access from the non-trusted client 118
- a disabled L bit 310 indicates that the owner is not allowed access from the non-trusted client 118 .
- This bit is applied in special situations when the owner of a filesystem object creates a filesystem object on the trusted client 116 , and wishes to access the filesystem object from another client, such as the non-trusted client 118 . In these situations, the owner can enable the L bit 310 , and add the client ID of the non-trusted client 118 in the inode of the object. Any number of non-trusted clients 118 can be added to the inode depending on the owner's requirement. Further, the owner can modify the list of the non-trusted clients 118 at any point of time.
- the owner mode bits 302 can be overloaded based on the T bit 308 , which means that access can be based on the owner mode bits 302 for different situations depending on the value of the T and L bits, and on the owner location. For example, if the T bit 308 is enabled (i.e., filesystem object was created on the trusted client 116 ) and the owner attempts to access the object from the trusted client 116 , access will be based on the owner mode bits 302 . On the other hand, if the owner makes an attempt to access the object from a non-trusted client 118 , the owner will be allowed access based on the other mode bits 306 .
- the access will be determined based on the owner mode bits 302 .
- the filesystem object is created from the non-trusted client 118 (i.e., the T bit 308 is disabled) access to the owner of the object can be based on the owner mode bits 302 in both cases (i.e., from a trusted 116 or a non-trusted client 118 ).
- the object was created on a non-trusted client 118 (i.e.. T bit is disabled), then access is not restricted only to the trusted clients 116 , but users on the non-trusted clients 118 can access the object as well, based on their access mode bits. Further, in this case, the group at trusted client mode bits 304 can be read as group mode bits, and even group members on the non-trusted clients 118 can be assessed against these mode bits.
- the access permissions can vary dynamically for the user 110 . Accordingly, based on the client ID, user ID, the T bit 308 , and the L bit 310 of the extended access permissions 300 , effective access permissions for an object can vary. For example, user 110 -A working on the client 106 -A owns a file “confidential.txt” with access permissions 755 . When the user 110 -A tries to access the file from the non-trusted client 118 , such as client 106 -D the access permissions of the object can dynamically change to 444 .
- FIG. 4 depicts a system 400 that includes the trusted clients 116 and the non-trusted clients 118 . Further, each of the trusted clients 116 and the non-trusted clients 118 are connected to an exemplary filesystem server, such as the filesystem server 104 -A. To illustrate the different scenarios further, an exemplary filesystem object is used. For instance, a filesystem object “confidential.txt” exists on the filesystem server 104 -A.
- the extended access permissions 300 of the object can be the permissions depicted below in Example 1 (as described in connection with FIG. 3 ).
- the extended access permissions 300 of Example 1 indicate that the owner at trusted client has full permissions (111), the users in the group at trusted client have read and execute permissions (101), and other has no permissions (000). Further the extended access permissions 300 indicate that the file was created on a trusted client (T bit 308 is enabled) and the owner can access the file from a non-trusted client 118 (L bit 310 is enabled).
- the user requesting access to the filesystem object—confidential.txt can be the owner of the object, a member of the owners group, or any other user. When the user tries to access the object from the trusted clients 116 , access will be based on the type of user.
- access will be based on the owner mode bits 302 and the owner 402 will be allowed complete access to the file.
- the group at trusted client mode bits 304 will be assessed and the user will be allowed to read and execute the file.
- access will be based on the other mode bits 306 and the user will not be allowed access to the file.
- the non-trusted clients ID is stored in the inode of the object, in this case, access will be based on the owner mode bits 302 , and the owner 402 will be allowed access.
- the ID for the non-trusted client 118 is not stored in the inode of the object, in this case, access will be based on the other mode bits 306 , and the owner 402 will not be allowed access to the file.
- the L bit 310 is enabled, but in case the L bit 310 was disabled, access would be based on the other mode bits 306 and the owner 402 would not be allowed access.
- access will be based on other's permissions 306 , and the user will not be allowed access to the file.
- access will be based on the other mode bits 306 and the user will not be allowed access, as the other mode bits 306 are 000 .
- a filesystem object “salary.txt” can have extended access permissions 300 as depicted below in Example 2:
- the extended access permissions 300 shown in Example 2 would indicate that the owner 402 created the file on the non-trusted client 118 (as the T bit 308 is disabled (0)). In this case, all users will be treated as if they were present on a trusted client 116 , even if they were present on a non-trusted client 118 , and access would be based on the access permissions of the first nine bits. However, if the owner 402 overwrites/replaces the file from the trusted client 116 , the T bit 308 will automatically be set to one (enabled), and the file will be treated as if it were created on the trusted client 116 .
- FIG. 5 illustrates an exemplary method 500 for providing access in the DFS 100 with reference to FIGS. 1 to 4 .
- the method 500 includes steps for granting access to a requested filesystem object in the DFS 100 . Further, the method 500 includes the steps of retrieving a user ID and a client ID, determining if a client is a misted client, looking up the extended access permissions 300 of the object, determining type of user, and providing access based on the extended access permissions 300 , and the user location.
- the method 500 retrieves the user ID and the client ID of the requested user.
- the requesting user can be the user 110 requesting access to a filesystem object on one of the filesystem servers 104 .
- the filesystem server 104 can retrieve the client ID of the client 106 and compare the client ID with the list of the clients 106 present either in the central repository 108 or in the memory 112 .
- the filesystem server 104 can utilize the NIS to retrieve the list of clients and the client ID. If the client ID is present in the list of client IDs, the NIS or the filesystem server 104 proceeds to check the user's identification. If the user ID is present along with the client ID, the user can be authenticated; else, the user is not authenticated.
- the user ID can be a unique value obtained through a combination of the user ID and the client ID. In another implementation, the user ID can be any unique value.
- the method 500 can determine whether the client ID corresponds to a trusted client or a non-trusted client.
- the filesystem server 104 can compare the client ID with the list of trusted clients stored in the central repository 108 or the memory 112 . If the client ID is present in the trusted clients, the client is a trusted client; else, the client is a non-trusted client. Trusted Computing can maintain the list of the trusted clients 116 and the non-trusted clients 118 .
- the NIS can be utilized to determine whether the client ID corresponds to a trusted or non-trusted client.
- the method 500 can look up the extended access permissions of the filesystem object at step 506 .
- the processing device 114 of the filesystem server 104 can obtain the extended access permissions 300 from the vnode 204 of the filesystem object.
- the extended access permissions 300 can be obtained from the inode of the object.
- the processing device 114 can determine user type at step 508 .
- the processing device 114 can determine the type of user from a list including owner, group member at trusted client, other user, owner at non-trusted client, or group member at non-trusted client.
- the filesystem server 104 can make the determination based on the user ID, the client ID, and the ownership information of the object. For example, if the user ID matches the owner ID in the inode of the object, and the client ID corresponds to the trusted client 116 , the filesystem server can determine that the user is the owner at trusted client. In another example, if the user ID does not match the owner ID or the group ID of the filesystem object, the filesystem server 104 can determine that the requesting user is an other user.
- the filesystem server 104 can either allow or deny access to the requesting user based on the user ID, the client ID, and the extended access permissions.
- the filesystem server checks whether the filesystem object was created on the trusted client 116 and whether the user is allowed to access the filesystem object from the non-trusted client 118 .
- the processing device 114 on the filesystem server 104 can check the T 308 and the L bit 310 of the extended access permissions 300 to determine whether the object was created on the trusted client 116 and whether a user on the non-trusted client 118 can access the object. Based on the determination, effective access permissions can be obtained for the object.
- the processing device 114 can evaluate the effective access permissions for the object each time the object is requested, based on the type of user and the extended access permissions 300 (as described in connection with FIG. 3 ). For example, if the type of user is group at trusted client, the filesystem sever 104 can provide access to the object based on the group at trusted client mode bits 304 . The access is provided based on a set of access rules, which will be described in detail with reference to FIG. 6 .
- the filesystem object is retrieved and presented on the client 106 .
- the inode number of the filesystem object can be checked to determine the location of the object on in the filesystem server 104 .
- the vnode 204 of the filesystem object can be checked to determine the location of the object in the DFS 100 .
- the requesting user will be allowed access as defined by the access mode bits pertaining to him/her. For example, if a user 110 has just the read permissions, then the user 110 cannot write/modify or execute the object.
- FIG. 6 is a flowchart illustrating an exemplary method 600 to determine whether a user should be granted access.
- the method 600 includes comparing the user ID and client ID with the access permissions to determine the accessibility.
- the method 600 determines whether the client is a trusted client 116 .
- the NIS can check whether the client ID matches with a trusted client ID.
- the list of the trusted clients 116 can be obtained from the central repository 108 or from the filesystem servers 104 .
- the processing device 114 can also check if the user ID of the requesting user 110 is present in a list of user IDs usually stored in memory of the client. In certain cases, the user IDs can also be stored along with the list of client IDs in the central repository 108 or in the memory 112 .
- the processing device 114 of the server checks whether the user 110 is a root user (step 604 ), else the processing device 114 proceeds to check whether the user ID corresponds to the owner ID, at step 606 .
- the method determines whether the user is a root user.
- the root user can be an administrator or a security advisor.
- the root user typically has all the access permissions in the DFS 100 . If the user 110 is the root user, the method 600 moves to step 618 and the user 110 is granted access to the filesystem object irrespective of die extended access permissions 300 of the object.
- the processing device 114 can determine whether the user 110 is a root user based on the user ID.
- the processing device 114 can check whether the user 110 is the owner 402 at step 608 .
- the user ID can be verified against the owner ID of the object.
- the owner ID can be acquired from the inode/vnode 204 of the object. If the IDs match, it can be determined that the user 110 is the owner 402 of the object. If the user is the owner 402 (‘yes’ path from step 608 ), the processing device 114 can refer the owner mode bits 302 at step 612 .
- the processing device 114 can check if the user 110 belongs to the group 404 (at step 610 ).
- the processing device can check the group ID of the object in the object vnode 204 /inode filesystem object. The users ID can be compared to the group ID of the object. If the user belongs to the group 404 mentioned in the vnode of the filesystem object, the group at trusted client mode, bits 304 can be referred (at step 616 ). If the user 110 has sufficient permissions based on the group at trusted client mode bits 304 , the user 110 is allowed access to the object: else, the user 110 is denied access.
- the other mode bits 306 are referred at step 614 . If the user 110 has access permissions based on the other mode bits 306 , the user 110 is granted access to the object, else denied.
- step 602 if the client was a non-trusted client 118 , the method 600 proceeds to step 606 .
- step 606 a determination is made whether the user 110 is the owner 402 of the object. If the user is the owner 402 (‘yes’ path from block 606 ), the method moves to step 620 , else the processing device 114 can refer the other mode bits 306 at step 614 (‘no’ path from block 606 ).
- the processing device 114 checks if the L bit 310 is enabled. If the L bit 310 is enabled (‘yes’ path from block 620 ) the method 600 moves to step 622 , else the method 600 moves to step 614 (‘no’ path from block 606 ) and the mode bits of other 306 is checked before access can be granted to the user 110 .
- the processing device 114 checks if the non-trusted client 118 is included in the vnode 204 of the object. If the non-trusted client 118 is mentioned in the vnode 204 of the object, the owner mode bits 302 are referred at step 612 , else access is based on the other mode bits 306 .
- the access can be based on the first 9 bits of the extended access permissions and the extended access permissions can be read as conventional access permissions.
Abstract
Description
- Filesystems are typically databases for the storage, hierarchical organization, manipulation, navigation, access, and retrieval of data. Distributed Filesystems (DFSs), a version of filesystems, have become increasingly widespread over the last few decades. A DFS, as the name suggests, is a network filesystem where a single filesystem can be distributed across several physical computing devices, and the computing devices can have direct access to a part of the entire filesystem. The DFS generally includes facilities for transparent replication and fault tolerance. That is, when a limited number of nodes in a filesystem go offline, the system continues to work without any data loss. Therefore, the DFS has become a very popular choice for local area networks (LAN) in organizations, corporations, and so on.
- In typical computer operating systems, files are stored with associated access permissions and users with sufficient access permissions are allowed to access the files. Conventionally, file access permissions are granted on three levels (i.e., owner, group, and other users). Each level can have its own permissions, and users can be granted access based on their level's access permissions. In addition, in most filesystems, each file has an associated owner identification (ID) (i.e., the ID of the user who created the filesystem object), and group ID (i.e., the owner can be part of one or more groups). The present file access permissions reduce chances of security breach (to a large extent) for local filesystems, where multiple users can access files from the same machine, but in distributed filesystems, the file access permissions can introduce vulnerabilities.
- In DFSs, multiple users present on different computing devices can access a single filesystem object. Therefore, the file access permissions create certain problems in DFSs. These problems occur because in DFSs it is not necessary for user IDs to be unique on all the computing devices in the system. For example, two users (such as user A and user B) can have the same user ID (such as ID 1000), on different client devices. So, when user A attempts to access a file created by user B, user A will be allowed access to the file (based on the owner access permissions of the file), even though user A did not create the file. The system permits this action as the file access permissions simply recognize user IDs, and since both the users have the same user ID, both user A and user B are recognized as owners of the file. Therefore, an authentic user can easily be faked, which can cause serious security threats.
- Various methods have been proposed to overcome sonic of the security issues in DFSs. Some methods centralize the user IDs and group IDs in a central repository, which ensures that no two users have the same user ID. Each time a user requests access to a file object, the user's credentials are verifyed against the repository. However, it is still possible to bypass the central repository and install a client device in the LAN. Further, a user can still fake a user ID on the new installed client device. In addition, since all riser IDs are stored in a central server, the entire system can crash if the central repository crashes.
- Other methods involve the use of public and private encryption keys. These methods also use a central repository, along with the encryption keys. Once a user is authenticated by the central repository, an additional level of security is added that requires an encryption key. Access is denied if the user does not possess the key. These systems can be very complex and require extensive training of administrators. Further, like the other methods known in the art, this method too has a single point of failure.
- Embodiments of the invention are directed to methods and systems for providing access to filesystem objects in a distributed filesystem.
- In a first embodiment, a method for providing access in a Distributed Filesystem (DFS) is described. The method includes the steps of retrieving a user identification (ID) and a client ID of a requesting user and determining whether the client ID corresponds to a trusted client or a non-trusted client. The method further includes obtaining extended access permissions of a filesystem object and allowing access to the filesystem object based on the user ID, the client ID, and the extended access permissions of the filesystem object. The extended access permissions of the object can include a T bit that indicates whether the filesystem object was created on a trusted client, and an L bit that indicates whether the requesting user is allowed to access the filesystem object from a non-trusted client.
- In a second embodiment, a system for providing access in a DFS is described. The system includes a memory and a processing device that are operatively coupled to retrieve a user ID and a client ID of a requesting user and determine whether the client ID corresponds to a trusted client or a non-trusted client. Moreover, the system obtains extended access permissions of a filesystem object, where the extended access permissions can include a T bit that indicates whether the filesystem object was created on a trusted client, and an L bit that indicates whether the requesting user is allowed to access the filesystem object from a non-trusted client. Further, the system allows access to the filesystem object based on the user ID, client ID and the extended access permissions of the filesystem object.
-
FIG. 1 is a block diagram illustrating an exemplary distributed filesystem (DFS) in which the claimed invention may operate. -
FIG. 2 illustrates a block diagram of a virtual filesystem of some embodiments of the claimed invention. -
FIG. 3 illustrates exemplary extended access permissions according to some embodiments of the claimed invention. -
FIG. 4 is a diagram illustrating exemplary scenarios in which a user can be allowed or denied access to a filesystem object. -
FIG. 5 is a flowchart of a method for providing access to filesystem objects in a distributed filesystem. -
FIG. 6 is a flowchart of a method for determining access to a filesystem object in a distributed filesystem. - The following detailed description is made with reference to the figures. Preferred embodiments are described to illustrate the claimed invention, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a variety of equivalent variations of the description that follows.
- An embodiment of the claimed invention describes a method for providing access in a distributed filesystem (DFS). The method allows authentic users to access filesystem objects. Further, the method allows users to access filesystem objects from authentic client devices. Another embodiment of the claimed invention uses a combination of user identification (ID) and client ID, to recognize unique users. Further, the concept of trusted computing is utilized in the claimed invention. In one embodiment, filesystem access permissions can be extended in order to enhance the security of objects in the distributed filesystem.
-
FIG. 1 is a block diagram illustrating an exemplary Distributed FileSystem (DFS) 100 in which the claimed invention may operate. The DFS 100 includes anetwork 102 that interconnects one or more filesystem server computing devices 104-A, 104-B (filesystem servers 104), one or more client computing devices 106-A, 106-B, 106-C, and 106-D (clients 106), and acentral repository 108. Further, one or more users 110-A, 110-B, 110-C, and 110-D (users 110) can access objects stored on thefilesystem servers 104, from theclients 106, through thenetwork 102. Filesystem objects can include files, directories, folders, documents, and other similar objects commonly stored on digital media. - In the DFS 100, various filesystems can be distributed across the
filesystem servers 104, which can be located in different geographical locations, but can logically be mapped under a root DFS folder. Therefore, theusers 110 are not required to know the exact location of thefilesystem servers 104. Further, theDFS 100 can include facilities for transparent replication and fault tolerance so that when a limited number of thefilesystem servers 104 go offline, theDFS 100 continues to work without any data loss. - The
network 102 may be any wired or wireless network known in the art. For example, the network can be a local area network (LAN), a metropolitan area network (MAN), the Internet, and so on. In one embodiment, thenetwork 102 is a private network, such as a company network, connecting a plurality of office PCs, various servers, and other computing-based devices spread throughout several countries. Alternately, thenetwork 102 includes a home network with a limited number of PCs belonging to a single family, connected over a WLAN. In other embodiments, thenetwork 102 can connect a limited number of clients in a small business. It will be appreciated that the type of network will not limit the scope of the invention, and any known network configuration can be used to implement theDFS 100. - Further, the
DFS 100 can function on any operating system known in the art, such as the IBM AIX® operating system, the Solaris Filesystem, the Linux filesystem, the Microsoft Windows® operating system, the MAC operating system, and so on. Embodiments of the claimed invention are described with reference to a UNIX operating system, though any operating system known in the art can be utilized instead. - Moreover, the
filesystem servers 104 and theclients 106 can be equipped with a memory, a processing device, input/output ports, networking ports, and so on. InFIG. 1 , the filesystem server 104-A is depicted with amemory 112 and aprocessing device 114. Theprocessing device 114 may include microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, theprocessing device 114 is configured to fetch and execute computer-readable instructions stored in thememory 112. Thememory 112 can include any computer-readable medium known in the art including, for example, volatile memory (e.g., RAM) and/or non-volatile memory (e.g., flash, etc.). Thememory 112 and theprocessing device 114 can have any suitable physical implementation and they can be operatively coupled depending on the particular device implementation. These components can be adapted, arranged, configured, and designed to perform methods in accordance with the teachings herein, for example, as illustratively described by reference toFIGS. 2-6 . It will be apparent to people of ordinary skill in art that each of theclients 106 and thefilesystem servers 104 can be equipped with a memory and a processing device. - Further, embodiments of the claimed invention restrict access to users on unauthorized clients (i.e. clients not recognized by the DFS 100), and allows access to authorized users on unauthorized clients. To this end, all the
clients 106 are divided into two groups, namely trusted clients and non-trusted clients, according to principles of trusted computing. - Trusted Computing (TC) is a technology developed and promoted by the Trusted Computing Group. With Trusted Computing, the
clients 106 consistently behave in specific ways enforced by hardware and software. Enforcing trusted behavior is achieved by loading the hardware with a unique ID and a unique master key and denying knowledge and control of the master key to even the owner of a client. Trusted Computing not only secures the hardware for the owner, but against the owner as well, thereby prohibiting users from faking authorized users. Many techniques are known in the art for implementing Trusted Computing, such as Network Filesystem (NFS). Network Information Service (NIS). Lightweight Directory Access Protocol (LDAP), and so on. Any of the known techniques can be used to implement TC. - In one implementation, NIS can be utilized. In NIS, the client IDs are stored in a central repository, such as the
central repository 108. Each client has a list of user IDs it can support. Since the client IDs are centrally stored, the NIS ensures that no two clients have the same user IDs, thereby ensuring unique user IDs. A new client installed in thenetwork 102 that tries to access thefilesystem servers 104 is treated as a non-trusted client, as NIS is not sure whether the client has unique user IDs. Once NIS configures the client and the user IDs on the client are in agreement with the user IDs on the trusted clients, the client can be upgraded to the trusted client group. -
FIG. 1 illustrates trustedclients 116 andnon-trusted clients 118. The trustedclients 116 include clients 106-A, 106-B, and 106-C, and thenon-trusted clients 118 include clients 106-D, 106-E. In one implementation, the trustedclients 116 and thenon-trusted clients 118 can be included in a list of clients stored in thememory 112 of thefilesystem servers 104. In another implementation, the list of clients can be stored in thecentral repository 108. Further, new clients in thenetwork 102 can be directly added to thenon-trusted clients 118. Once NIS authenticates the user IDs, the clients can be upgraded to the trustedclients 116. - When a user requests for a filesystem object on the
DFS 100, the NIS verifies the user's client ID against the list of clients. If the user's client ID is not present in the list of clients, the NIS does not allow access to theuser 110. In case the client ID is present in the list of clients, thefilesystem server 104 confirms if theuser 110 has presented the correct user ID. Based on the confirmation, the user ID is checked against, the access permissions of the filesystem object. - In this manner, embodiments the claimed invention ensures that the
users 110 can have unique identification and clients that are not part of the unique identification scheme can be thenon-trusted clients 118. The separation of the trusted and non-trusted clients allows thefilesystem servers 104 to allow authentic users on the trustedclients 116 to access thefilesystem server 104 and at the same time deny access to fake users on thenon-trusted clients 118. - Moreover, a number of techniques can be utilized to uniquely identify the
users 110. In one implementation, users can be identified by using a combination of user ID and client ID, where the client ID corresponds to the client that the user typically operates on. The combination of the user ID and the client ID can be in any form, such as numerical values, alphanumeric, values, user names, MAC addresses, user personal information, and so on. In another implementation, any unique ID such as a numeric value, an alphanumeric value, etc., can be considered as a user ID. - Therefore, according to embodiments of the claimed invention, access to filesystem objects is based on the user ID, the client ID, and the access permissions of a filesystem object. Since, the users are defined not only by their user IDs, but also their respective locations (if the user is on a trusted or a non-trusted client), the conventional access permissions of the objects have to be modified in order to provide different access permissions based on the location of the user. To this end, embodiments of the claimed invention add some new bits to the access permissions of the current filesystems and overload the existing access permission bits. An explanation of extended access permissions is provided in conjunction with
FIG. 3 . - The following sections describe conventional file access schemes as some prior knowledge about the conventional access permissions is required to understand the extended access permissions of the claimed invention. The conventional access permissions will be explained with reference to the UNIX operating system. However, it will be appreciated that conventional access permissions can be explained with reference to any other operating system known in the art. Each operating system has its own syntax, commands, file names, etc., but the basic concept of conventional access permissions remains the same in typical operating systems.
- In UNIX, a user ID and at least one group ID can be used to identify a user. Furthermore, users in one group can be classified under one group ID. For example, an organization can have various teams, such as a financial team, a human resources team, an IT team and so on. The members of the financial team can be grouped under a financial group ID, the human resources team can be grouped under a human resources group ID, and so on. Further, the managers of the teams can be organized under an executive group ID. An administrator or a root user can manage the group IDs. Typically, all filesystem objects include the user ID of the owner that created the filesystem object and the group ID of the group to which the owner belongs.
- Conventional access permissions can be permissions such as read, write, and execute permissions for different levels of users, such as owner of the object, group member, or any other user. UNIX typically assigns 9-bit access permissions, which can be depicted as three octal digits. Each octal digit represents permissions for the owner, the group member, or any other user respectively. The first octal digit represents the access permissions for the owner of the object, the next octal digit represents the access allowed for members of a group to which the owner belongs, and the last octal digit represents access permissions for any other user. Further, each binary bit of the octal digit can represent individual permissions, such as read, write, and execute permissions. The first bit indicates read permission, the second bit indicates write permission, and the third bit indicates execute permission. If the bit value is 1, the permission is activated, else, the permission is blocked. For example, an
octal digit 7 has a binary value of 111, which indicates that the user has read, write, and execute permissions for the filesystem object. - An authorized user, such as the owner of the object or an administrator, typically assigns the access permissions. In some situations, the access permissions can be preset for processes, or an environment, so all the objects created in that process or environment will automatically have the access permissions assigned to that process or environment. An authorized user can modify the access permissions of an object at any time after its creation.
- In the UNIX system, the conventional access permissions are stored in a metadata file called inode, which stores basic information about a regular file, directory, or other filesystem object. Each filesystem object can have an inode and an inode number (often referred to as an “i-number” or “inode”) that can identify the inode in the filesystem and where it resides.
- Typically inodes store information about filesystem objects, such as the user ID of the owner, and the group ID, access permissions (read, write, execute permissions) and type of object. Further, the inode number indexes a table of inodes in a known location on the device; from the inode number, the kernel can access the contents of the inode and the contents of the filesystem object. Conventionally, the kernel searches a directory looking for a particular filename and then converts the filename to the correct corresponding inode number.
- The
DFS 100 has a number of filesystems, and in certain embodiments, the filesystems can be of different types, such as the Solaris® filesystem, the Linux® filesystem, the Windows® filesystems, the Mac OS filesystems, the UNIX® filesystems, and so on. Each of thefilesystem servers 104 can have their own manner of storing the metadata about the filesystem objects. In order to for a user to seamlessly access the objects from different filesystems, a virtual filesystem (VFS) abstraction layer can be present on top of thefilesystem servers 104 in theDFS 100. -
FIG. 2 depicts aVFS 202 and its relation with thevarious filesystem servers 104. TheVFS 202 can allow theclients 106 to access different types of thefilesystem servers 104 in a uniform manner. Moreover, theVFS 202 can, for example, be used to access local and network servers transparently without theclients 106 noticing the difference. In one implementation. TheVFS 202 bridges the differences in various filesystems, so that theclients 106 can access objects on the filesystems without having to know the type of filesystem. - To retrieve the modes of different filesystems, the
VFS 202 uses a data structure called avnode 204. All file manipulations can be done with thevnode 204, which includes public and private data. The public data fields in each vnode 204 either include data that is manipulated only by theVFS 202 layer or data about the filesystem object that does not change over the life of the filesystem object, such as the file type. The private data fields in thevnode 204 point to data that is dependent on the filesystem, such as the inode table of the filesystem. Thevnode 204 is depicted with inode table entries of thefilesystem servers 104. - The
vnode 204 of the filesystem can point to inode numbers of the filesystem objects of aparticular filesystem server 104. Therefore, in theDFS 100, the access permissions of objects can be accessed through the vnode and/or the inode of the filesystem object. Further, the access permissions field in the inode is typically a 16-bit field. Presently, 9 of these 16 bits are used to define the conventional access permissions of the filesystem object, while 3 bits are used for special purpose security, which leaves four unused bits in the 16-bit access permission field. -
FIG. 3 illustrates exemplaryextended access permissions 300 according to embodiments of the claimed invention. The exemplaryextended access permissions 300 include 11 bits as opposed to the conventional 9-bit access permissions explained above. Embodiments of the claimed invention utilize two of the four unused bits in the access permissions field. The first 9 bits of the extended access permissions 300 (that can be represented as three octal digits) are used to indicateowner mode bits 302, group on a trustedclient mode bits 304, and other (everyone else)mode bits 306. Furthermore, embodiments of the claimed invention alter the definition of the mode bits. Typically, the second octal digit represented access permissions for group members, but according to the claimed invention, the second octal digit indicates access permissions for the group members accessing the object from the trustedclients 116. Further, the thirdoctal digit 306 indicates permissions for other, rather than for others as done previously. In some implementations, theother mode bits 306 can be checked for owners on thenon-trusted clients 118, group members on thenon-trusted clients 118, or other users. - The tenth and eleventh bits can be a
T bit 308 and anL bit 310 that are introduced in an embodiment of the claimed invention. TheT bit 308 indicates whether the filesystem object was created on the trustedclients 116 or on thenon-trusted clients 118. An enabled status (e.g., bit value 1) on theT bit 308 indicates that the filesystem object was created on the trustedclients 116, while a disabled status (e.g., bit value 0) on theT bit 308 indicates that the filesystem object was created on thenon-trusted clients 118. In one implementation, the processing device can automatically set theT bit 308, once the object has been created. Further, in cases when the owner is allowed access to the object and the owner modifies the object from the trustedclients 116, theT bit 308 can be automatically enabled, if previously disabled. - The
L bit 310 indicates whether the owner of an object is allowed access to the object, wherein the owner is a user on anon-trusted client 118. To this end, an enabledL bit 310 indicates that the owner is allowed access from thenon-trusted client 118, while adisabled L bit 310 indicates that the owner is not allowed access from thenon-trusted client 118. This bit is applied in special situations when the owner of a filesystem object creates a filesystem object on the trustedclient 116, and wishes to access the filesystem object from another client, such as thenon-trusted client 118. In these situations, the owner can enable theL bit 310, and add the client ID of thenon-trusted client 118 in the inode of the object. Any number ofnon-trusted clients 118 can be added to the inode depending on the owner's requirement. Further, the owner can modify the list of thenon-trusted clients 118 at any point of time. - In one implementation, the
owner mode bits 302 can be overloaded based on theT bit 308, which means that access can be based on theowner mode bits 302 for different situations depending on the value of the T and L bits, and on the owner location. For example, if theT bit 308 is enabled (i.e., filesystem object was created on the trusted client 116) and the owner attempts to access the object from the trustedclient 116, access will be based on theowner mode bits 302. On the other hand, if the owner makes an attempt to access the object from anon-trusted client 118, the owner will be allowed access based on theother mode bits 306. In situations when theL bit 310 is enabled and the owner endeavors to access the object from a non-trusted client 118 (and the non-trusted client ID is present in the inode of the object), the access will be determined based on theowner mode bits 302. In addition, if the filesystem object is created from the non-trusted client 118 (i.e., theT bit 308 is disabled) access to the owner of the object can be based on theowner mode bits 302 in both cases (i.e., from a trusted 116 or a non-trusted client 118). - If the object was created on a non-trusted client 118 (i.e.. T bit is disabled), then access is not restricted only to the trusted
clients 116, but users on thenon-trusted clients 118 can access the object as well, based on their access mode bits. Further, in this case, the group at trustedclient mode bits 304 can be read as group mode bits, and even group members on thenon-trusted clients 118 can be assessed against these mode bits. - Since, access to a
user 110 not only depends on the user ID, but also the client ID, the access permissions can vary dynamically for theuser 110. Accordingly, based on the client ID, user ID, theT bit 308, and theL bit 310 of theextended access permissions 300, effective access permissions for an object can vary. For example, user 110-A working on the client 106-A owns a file “confidential.txt” with access permissions 755. When the user 110-A tries to access the file from thenon-trusted client 118, such as client 106-D the access permissions of the object can dynamically change to 444. - Turning now to
FIG. 4 , which illustrates some exemplary scenarios in which a user can be allowed or denied access to a filesystem object.FIG. 4 depicts a system 400 that includes the trustedclients 116 and thenon-trusted clients 118. Further, each of the trustedclients 116 and thenon-trusted clients 118 are connected to an exemplary filesystem server, such as the filesystem server 104-A. To illustrate the different scenarios further, an exemplary filesystem object is used. For instance, a filesystem object “confidential.txt” exists on the filesystem server 104-A. Theextended access permissions 300 of the object can be the permissions depicted below in Example 1 (as described in connection withFIG. 3 ). -
1 1 1 1 0 1 0 0 0 1 1 - The
extended access permissions 300 of Example 1 indicate that the owner at trusted client has full permissions (111), the users in the group at trusted client have read and execute permissions (101), and other has no permissions (000). Further theextended access permissions 300 indicate that the file was created on a trusted client (T bit 308 is enabled) and the owner can access the file from a non-trusted client 118 (L bit 310 is enabled). The user requesting access to the filesystem object—confidential.txt can be the owner of the object, a member of the owners group, or any other user. When the user tries to access the object from the trustedclients 116, access will be based on the type of user. For example, when the user is anowner 402, access will be based on theowner mode bits 302 and theowner 402 will be allowed complete access to the file. When the user is in agroup 404, the group at trustedclient mode bits 304 will be assessed and the user will be allowed to read and execute the file. When the user is another user 406, access will be based on theother mode bits 306 and the user will not be allowed access to the file. - Now in another scenario, when the user attempts to access the file “confidentical.txt” from a
non-trusted client 118, a number of outcomes are possible. When the user is theowner 402, two situations are possible. In the first situation, the non-trusted clients ID is stored in the inode of the object, in this case, access will be based on theowner mode bits 302, and theowner 402 will be allowed access. In the second situation, the ID for thenon-trusted client 118 is not stored in the inode of the object, in this case, access will be based on theother mode bits 306, and theowner 402 will not be allowed access to the file. According to the present example, theL bit 310 is enabled, but in case theL bit 310 was disabled, access would be based on theother mode bits 306 and theowner 402 would not be allowed access. - When the user is in the
group 404, access will be based on other'spermissions 306, and the user will not be allowed access to the file. Finally, when the user is theother user 406, access will be based on theother mode bits 306 and the user will not be allowed access, as theother mode bits 306 are 000. - Further, in another example, a filesystem object “salary.txt” can have extended
access permissions 300 as depicted below in Example 2: -
1 1 1 1 0 1 0 0 0 0 0 - The
extended access permissions 300 shown in Example 2 would indicate that theowner 402 created the file on the non-trusted client 118 (as theT bit 308 is disabled (0)). In this case, all users will be treated as if they were present on a trustedclient 116, even if they were present on anon-trusted client 118, and access would be based on the access permissions of the first nine bits. However, if theowner 402 overwrites/replaces the file from the trustedclient 116, theT bit 308 will automatically be set to one (enabled), and the file will be treated as if it were created on the trustedclient 116. -
FIG. 5 illustrates anexemplary method 500 for providing access in theDFS 100 with reference toFIGS. 1 to 4 . Themethod 500 includes steps for granting access to a requested filesystem object in theDFS 100. Further, themethod 500 includes the steps of retrieving a user ID and a client ID, determining if a client is a misted client, looking up theextended access permissions 300 of the object, determining type of user, and providing access based on theextended access permissions 300, and the user location. - At
step 502, themethod 500 retrieves the user ID and the client ID of the requested user. The requesting user can be theuser 110 requesting access to a filesystem object on one of thefilesystem servers 104. In one embodiment, thefilesystem server 104 can retrieve the client ID of theclient 106 and compare the client ID with the list of theclients 106 present either in thecentral repository 108 or in thememory 112. In another embodiment, thefilesystem server 104 can utilize the NIS to retrieve the list of clients and the client ID. If the client ID is present in the list of client IDs, the NIS or thefilesystem server 104 proceeds to check the user's identification. If the user ID is present along with the client ID, the user can be authenticated; else, the user is not authenticated. In one implementation, the user ID can be a unique value obtained through a combination of the user ID and the client ID. In another implementation, the user ID can be any unique value. - At
step 504, themethod 500 can determine whether the client ID corresponds to a trusted client or a non-trusted client. In one embodiment, thefilesystem server 104 can compare the client ID with the list of trusted clients stored in thecentral repository 108 or thememory 112. If the client ID is present in the trusted clients, the client is a trusted client; else, the client is a non-trusted client. Trusted Computing can maintain the list of the trustedclients 116 and thenon-trusted clients 118. For example, the NIS can be utilized to determine whether the client ID corresponds to a trusted or non-trusted client. - Upon determining whether the client is a trusted or non-trusted client, the
method 500 can look up the extended access permissions of the filesystem object atstep 506. In one implementation, theprocessing device 114 of thefilesystem server 104 can obtain theextended access permissions 300 from thevnode 204 of the filesystem object. In another implementation, theextended access permissions 300 can be obtained from the inode of the object. - Once the
extended access permissions 300 are obtained, theprocessing device 114 can determine user type atstep 508. In one implementation, theprocessing device 114 can determine the type of user from a list including owner, group member at trusted client, other user, owner at non-trusted client, or group member at non-trusted client. Thefilesystem server 104 can make the determination based on the user ID, the client ID, and the ownership information of the object. For example, if the user ID matches the owner ID in the inode of the object, and the client ID corresponds to the trustedclient 116, the filesystem server can determine that the user is the owner at trusted client. In another example, if the user ID does not match the owner ID or the group ID of the filesystem object, thefilesystem server 104 can determine that the requesting user is an other user. - At
step 510, thefilesystem server 104 can either allow or deny access to the requesting user based on the user ID, the client ID, and the extended access permissions. In one implementation, the filesystem server checks whether the filesystem object was created on the trustedclient 116 and whether the user is allowed to access the filesystem object from thenon-trusted client 118. In one implementation, theprocessing device 114 on thefilesystem server 104 can check theT 308 and theL bit 310 of theextended access permissions 300 to determine whether the object was created on the trustedclient 116 and whether a user on thenon-trusted client 118 can access the object. Based on the determination, effective access permissions can be obtained for the object. Theprocessing device 114 can evaluate the effective access permissions for the object each time the object is requested, based on the type of user and the extended access permissions 300 (as described in connection withFIG. 3 ). For example, if the type of user is group at trusted client, the filesystem sever 104 can provide access to the object based on the group at trustedclient mode bits 304. The access is provided based on a set of access rules, which will be described in detail with reference toFIG. 6 . - If at the output of the
step 510, the requesting user is allowed access to the filesystem object, the filesystem object is retrieved and presented on theclient 106. In one implementation, the inode number of the filesystem object can be checked to determine the location of the object on in thefilesystem server 104. In another implementation, thevnode 204 of the filesystem object can be checked to determine the location of the object in theDFS 100. Further, the requesting user will be allowed access as defined by the access mode bits pertaining to him/her. For example, if auser 110 has just the read permissions, then theuser 110 cannot write/modify or execute the object. -
FIG. 6 is a flowchart illustrating anexemplary method 600 to determine whether a user should be granted access. Themethod 600 includes comparing the user ID and client ID with the access permissions to determine the accessibility. - At
step 602, themethod 600 determines whether the client is a trustedclient 116. In one implementation, the NIS can check whether the client ID matches with a trusted client ID. The list of the trustedclients 116 can be obtained from thecentral repository 108 or from thefilesystem servers 104. In one implementation, theprocessing device 114 can also check if the user ID of the requestinguser 110 is present in a list of user IDs usually stored in memory of the client. In certain cases, the user IDs can also be stored along with the list of client IDs in thecentral repository 108 or in thememory 112. - If the client is a trusted client 116 (‘yes’ path from step 602), the
processing device 114 of the server checks whether theuser 110 is a root user (step 604), else theprocessing device 114 proceeds to check whether the user ID corresponds to the owner ID, atstep 606. - At
step 604, the method determines whether the user is a root user. The root user can be an administrator or a security advisor. The root user typically has all the access permissions in theDFS 100. If theuser 110 is the root user, themethod 600 moves to step 618 and theuser 110 is granted access to the filesystem object irrespective of dieextended access permissions 300 of the object. Theprocessing device 114 can determine whether theuser 110 is a root user based on the user ID. - If the
user 110 is not the root user, theprocessing device 114 can check whether theuser 110 is theowner 402 atstep 608. In one implementation, the user ID can be verified against the owner ID of the object. In one implementation, the owner ID can be acquired from the inode/vnode 204 of the object. If the IDs match, it can be determined that theuser 110 is theowner 402 of the object. If the user is the owner 402 (‘yes’ path from step 608), theprocessing device 114 can refer theowner mode bits 302 atstep 612. - If the IDs do not match (‘no’ path from step 608) the
processing device 114 can check if theuser 110 belongs to the group 404 (at step 610). In one implementation, the processing device can check the group ID of the object in theobject vnode 204/inode filesystem object. The users ID can be compared to the group ID of the object. If the user belongs to thegroup 404 mentioned in the vnode of the filesystem object, the group at trusted client mode,bits 304 can be referred (at step 616). If theuser 110 has sufficient permissions based on the group at trustedclient mode bits 304, theuser 110 is allowed access to the object: else, theuser 110 is denied access. - If the
user 110 does not belong to thegroup 404, then theother mode bits 306 are referred atstep 614. If theuser 110 has access permissions based on theother mode bits 306, theuser 110 is granted access to the object, else denied. - Further, at
step 602, if the client was anon-trusted client 118, themethod 600 proceeds to step 606. Atstep 606, a determination is made whether theuser 110 is theowner 402 of the object. If the user is the owner 402 (‘yes’ path from block 606), the method moves to step 620, else theprocessing device 114 can refer theother mode bits 306 at step 614 (‘no’ path from block 606). - At
step 620, theprocessing device 114 checks if theL bit 310 is enabled. If theL bit 310 is enabled (‘yes’ path from block 620) themethod 600 moves to step 622, else themethod 600 moves to step 614 (‘no’ path from block 606) and the mode bits of other 306 is checked before access can be granted to theuser 110. - At
step 622, theprocessing device 114 checks if thenon-trusted client 118 is included in thevnode 204 of the object. If thenon-trusted client 118 is mentioned in thevnode 204 of the object, theowner mode bits 302 are referred atstep 612, else access is based on theother mode bits 306. - Further, in
method 600, if the T bit is disabled (e.g., 0), then the access can be based on the first 9 bits of the extended access permissions and the extended access permissions can be read as conventional access permissions. - The description set out above describe particular embodiments only and is not intended to limit the invention, whose scope is determined solely by the claims set out below. As used here, singular forms “a”, “an” and “the” are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of slated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
- The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the claimed invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (17)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/402,764 US8886672B2 (en) | 2009-03-12 | 2009-03-12 | Providing access in a distributed filesystem |
PCT/EP2010/052518 WO2010102914A1 (en) | 2009-03-12 | 2010-03-01 | Distributed filesystem access |
CN201080010778.0A CN102341809B (en) | 2009-03-12 | 2010-03-01 | Distributed filesystem access |
JP2011553388A JP5506829B2 (en) | 2009-03-12 | 2010-03-01 | Distributed file system access |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/402,764 US8886672B2 (en) | 2009-03-12 | 2009-03-12 | Providing access in a distributed filesystem |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100235396A1 true US20100235396A1 (en) | 2010-09-16 |
US8886672B2 US8886672B2 (en) | 2014-11-11 |
Family
ID=42111714
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/402,764 Active 2030-10-26 US8886672B2 (en) | 2009-03-12 | 2009-03-12 | Providing access in a distributed filesystem |
Country Status (4)
Country | Link |
---|---|
US (1) | US8886672B2 (en) |
JP (1) | JP5506829B2 (en) |
CN (1) | CN102341809B (en) |
WO (1) | WO2010102914A1 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130339406A1 (en) * | 2012-06-19 | 2013-12-19 | Infinidat Ltd. | System and method for managing filesystem objects |
WO2016161396A1 (en) * | 2015-04-01 | 2016-10-06 | Datto, Inc. | Network attached storage (nas) apparatus having reversible privacy settings for logical storage area shares, and methods of configuring same |
US9628486B2 (en) * | 2014-10-23 | 2017-04-18 | Vormetric, Inc. | Access control for data blocks in a distributed filesystem |
US9836347B2 (en) | 2013-08-09 | 2017-12-05 | Datto, Inc. | Apparatuses, methods and systems for determining a virtual machine state |
WO2018148597A1 (en) * | 2017-02-10 | 2018-08-16 | BlueTalon, Inc. | Authentication based on client access limitation |
US10250723B2 (en) | 2017-04-13 | 2019-04-02 | BlueTalon, Inc. | Protocol-level identity mapping |
US10291602B1 (en) | 2017-04-12 | 2019-05-14 | BlueTalon, Inc. | Yarn rest API protection |
US10367824B2 (en) | 2016-03-04 | 2019-07-30 | BlueTalon, Inc. | Policy management, enforcement, and audit for data security |
US10664529B2 (en) | 2004-09-03 | 2020-05-26 | Open Text Sa Ulc | Systems and methods for escalating a collaboration interface |
US11005889B1 (en) | 2018-02-02 | 2021-05-11 | Microsoft Technology Licensing, Llc | Consensus-based policy management |
US20210240768A1 (en) * | 2020-02-05 | 2021-08-05 | EMC IP Holding Company LLC | Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace |
US11138153B2 (en) * | 2010-05-27 | 2021-10-05 | Varonis Systems, Inc. | Data tagging |
US11146563B1 (en) | 2018-01-31 | 2021-10-12 | Microsoft Technology Licensing, Llc | Policy enforcement for search engines |
US11790099B1 (en) | 2018-02-09 | 2023-10-17 | Microsoft Technology Licensing, Llc | Policy enforcement for dataset access in distributed computing environment |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160277410A1 (en) * | 2015-03-17 | 2016-09-22 | StoryCloud, Inc. | Method and apparatus for transmission and reception of secure ephemeral media |
US10032045B2 (en) | 2015-10-30 | 2018-07-24 | Raytheon Company | Dynamic runtime field-level access control using a hierarchical permission context structure |
CN106682003B (en) * | 2015-11-06 | 2019-09-20 | 中国电信股份有限公司 | The path segmentation mapping method and device of distributed storage NameSpace |
CN105656949A (en) * | 2016-04-01 | 2016-06-08 | 浪潮(北京)电子信息产业有限公司 | Access control method and system of network file system |
CN106778327A (en) * | 2016-11-28 | 2017-05-31 | 龙存(苏州)科技有限公司 | A kind of safety certifying method of distributed file system |
CN109558433B (en) * | 2017-09-27 | 2022-04-12 | 北京京东尚科信息技术有限公司 | Method and device for requesting access to HDFS |
CN108289098B (en) * | 2018-01-12 | 2021-07-06 | 百度在线网络技术(北京)有限公司 | Authority management method and device of distributed file system, server and medium |
US11622000B2 (en) | 2021-01-29 | 2023-04-04 | Salesforce, Inc. | Grey failure handling in distributed storage systems |
US11741050B2 (en) | 2021-01-29 | 2023-08-29 | Salesforce, Inc. | Cloud storage class-based variable cache availability |
US11509721B2 (en) | 2021-01-31 | 2022-11-22 | Salesforce.Com, Inc. | Cookie-based network location of storage nodes in cloud |
CN117436079B (en) * | 2023-12-20 | 2024-04-05 | 麒麟软件有限公司 | Integrity protection method and system for Linux system |
Citations (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5764889A (en) * | 1996-09-26 | 1998-06-09 | International Business Machines Corporation | Method and apparatus for creating a security environment for a user task in a client/server system |
US5933826A (en) * | 1997-03-21 | 1999-08-03 | Novell, Inc. | Method and apparatus for securing and storing executable content |
US6092203A (en) * | 1995-11-29 | 2000-07-18 | Hitachi, Ltd. | Method for accessing information |
US6105027A (en) * | 1997-03-10 | 2000-08-15 | Internet Dynamics, Inc. | Techniques for eliminating redundant access checking by access filters |
US6125447A (en) * | 1997-12-11 | 2000-09-26 | Sun Microsystems, Inc. | Protection domains to provide security in a computer system |
US6289462B1 (en) * | 1998-09-28 | 2001-09-11 | Argus Systems Group, Inc. | Trusted compartmentalized computer operating system |
US6308273B1 (en) * | 1998-06-12 | 2001-10-23 | Microsoft Corporation | Method and system of security location discrimination |
US6405202B1 (en) * | 1998-04-27 | 2002-06-11 | Trident Systems, Inc. | System and method for adding property level security to an object oriented database |
US20030050962A1 (en) * | 1999-10-07 | 2003-03-13 | Robert Charles Monsen | Method and apparatus for securing information access |
US20030135545A1 (en) * | 2000-07-28 | 2003-07-17 | Bunichiroh Fujii | Method for permitting reproduction of content file and recorded medium on which reproduction software for reproducing content file is recorded |
US6714930B1 (en) * | 2000-05-31 | 2004-03-30 | International Business Machines Corporation | Lightweight directory access protocol, (LDAP) trusted processing of unique identifiers |
US20040193919A1 (en) * | 2003-03-31 | 2004-09-30 | Dabbish Ezzat A. | Method and apparatus for identifying trusted devices |
US20040236961A1 (en) * | 1997-07-15 | 2004-11-25 | Walmsley Simon Robert | Integrated circuit incorporating protection from power supply attacks |
US20040250113A1 (en) * | 2003-04-16 | 2004-12-09 | Silicon Graphics, Inc. | Clustered filesystem for mix of trusted and untrusted nodes |
US20050240901A1 (en) * | 2004-04-23 | 2005-10-27 | International Business Machines Corporation | Object set property viewer |
US20060064759A1 (en) * | 2004-09-22 | 2006-03-23 | Wildlife Acoustics, Inc. | Method and apparatus for controlling access to downloadable content |
US20060089909A1 (en) * | 2004-10-21 | 2006-04-27 | First National Technologies Inc. | Cardless transaction system |
US20060117378A1 (en) * | 2004-11-04 | 2006-06-01 | Tam Chung M | System and method for creating a secure trusted social network |
US20060114917A1 (en) * | 2002-12-20 | 2006-06-01 | Christoph Raisch | Secure system and method for san management in a non-trusted server environment |
US7076795B2 (en) * | 2002-01-11 | 2006-07-11 | International Business Machiness Corporation | System and method for granting access to resources |
US20060294580A1 (en) * | 2005-06-28 | 2006-12-28 | Yeh Frank Jr | Administration of access to computer resources on a network |
US20070118902A1 (en) * | 2002-06-17 | 2007-05-24 | Bae Systems Information Technology Llc | Process isolation by limiting covert storage channels in trusted operating system |
US20070214497A1 (en) * | 2006-03-10 | 2007-09-13 | Axalto Inc. | System and method for providing a hierarchical role-based access control |
US20080089295A1 (en) * | 2002-05-29 | 2008-04-17 | Keeler James D | System and Method of User Access Service Levels in a Distributed Network Communication System |
US20080313417A1 (en) * | 2007-06-18 | 2008-12-18 | Su Yong Kim | Apparatus and method of detecting and controlling privilege level violation process |
US20100010998A1 (en) * | 2008-07-09 | 2010-01-14 | The Go Daddy Group, Inc. | Document storage access on a time-based approval basis |
US7676845B2 (en) * | 2005-03-24 | 2010-03-09 | Microsoft Corporation | System and method of selectively scanning a file on a computing device for malware |
US7827598B2 (en) * | 2001-07-12 | 2010-11-02 | International Business Machines Corporation | Grouped access control list actions |
US20110035787A1 (en) * | 2008-04-11 | 2011-02-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Access Through Non-3GPP Access Networks |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5742759A (en) | 1995-08-18 | 1998-04-21 | Sun Microsystems, Inc. | Method and system for facilitating access control to system resources in a distributed computer system |
EP0966822A2 (en) | 1997-03-10 | 1999-12-29 | Internet Dynamics, Inc. | Methods and apparatus for controlling access to information |
JP2002342144A (en) | 2001-05-21 | 2002-11-29 | Toshiba Corp | File sharing system, program and file transferring method |
US20170118214A1 (en) | 2001-12-12 | 2017-04-27 | Pervasive Security Systems, Inc. | Method and architecture for providing access to secured data from non-secured clients |
-
2009
- 2009-03-12 US US12/402,764 patent/US8886672B2/en active Active
-
2010
- 2010-03-01 JP JP2011553388A patent/JP5506829B2/en active Active
- 2010-03-01 WO PCT/EP2010/052518 patent/WO2010102914A1/en active Application Filing
- 2010-03-01 CN CN201080010778.0A patent/CN102341809B/en active Active
Patent Citations (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6092203A (en) * | 1995-11-29 | 2000-07-18 | Hitachi, Ltd. | Method for accessing information |
US5764889A (en) * | 1996-09-26 | 1998-06-09 | International Business Machines Corporation | Method and apparatus for creating a security environment for a user task in a client/server system |
US6105027A (en) * | 1997-03-10 | 2000-08-15 | Internet Dynamics, Inc. | Techniques for eliminating redundant access checking by access filters |
US5933826A (en) * | 1997-03-21 | 1999-08-03 | Novell, Inc. | Method and apparatus for securing and storing executable content |
US20040236961A1 (en) * | 1997-07-15 | 2004-11-25 | Walmsley Simon Robert | Integrated circuit incorporating protection from power supply attacks |
US6125447A (en) * | 1997-12-11 | 2000-09-26 | Sun Microsystems, Inc. | Protection domains to provide security in a computer system |
US6405202B1 (en) * | 1998-04-27 | 2002-06-11 | Trident Systems, Inc. | System and method for adding property level security to an object oriented database |
US6308273B1 (en) * | 1998-06-12 | 2001-10-23 | Microsoft Corporation | Method and system of security location discrimination |
US6289462B1 (en) * | 1998-09-28 | 2001-09-11 | Argus Systems Group, Inc. | Trusted compartmentalized computer operating system |
US20030050962A1 (en) * | 1999-10-07 | 2003-03-13 | Robert Charles Monsen | Method and apparatus for securing information access |
US6714930B1 (en) * | 2000-05-31 | 2004-03-30 | International Business Machines Corporation | Lightweight directory access protocol, (LDAP) trusted processing of unique identifiers |
US20030135545A1 (en) * | 2000-07-28 | 2003-07-17 | Bunichiroh Fujii | Method for permitting reproduction of content file and recorded medium on which reproduction software for reproducing content file is recorded |
US7827598B2 (en) * | 2001-07-12 | 2010-11-02 | International Business Machines Corporation | Grouped access control list actions |
US7076795B2 (en) * | 2002-01-11 | 2006-07-11 | International Business Machiness Corporation | System and method for granting access to resources |
US20080089295A1 (en) * | 2002-05-29 | 2008-04-17 | Keeler James D | System and Method of User Access Service Levels in a Distributed Network Communication System |
US20070118902A1 (en) * | 2002-06-17 | 2007-05-24 | Bae Systems Information Technology Llc | Process isolation by limiting covert storage channels in trusted operating system |
US20060114917A1 (en) * | 2002-12-20 | 2006-06-01 | Christoph Raisch | Secure system and method for san management in a non-trusted server environment |
US20040193919A1 (en) * | 2003-03-31 | 2004-09-30 | Dabbish Ezzat A. | Method and apparatus for identifying trusted devices |
US20040250113A1 (en) * | 2003-04-16 | 2004-12-09 | Silicon Graphics, Inc. | Clustered filesystem for mix of trusted and untrusted nodes |
US20050240901A1 (en) * | 2004-04-23 | 2005-10-27 | International Business Machines Corporation | Object set property viewer |
US20060064759A1 (en) * | 2004-09-22 | 2006-03-23 | Wildlife Acoustics, Inc. | Method and apparatus for controlling access to downloadable content |
US20060089909A1 (en) * | 2004-10-21 | 2006-04-27 | First National Technologies Inc. | Cardless transaction system |
US20060117378A1 (en) * | 2004-11-04 | 2006-06-01 | Tam Chung M | System and method for creating a secure trusted social network |
US7676845B2 (en) * | 2005-03-24 | 2010-03-09 | Microsoft Corporation | System and method of selectively scanning a file on a computing device for malware |
US20060294580A1 (en) * | 2005-06-28 | 2006-12-28 | Yeh Frank Jr | Administration of access to computer resources on a network |
US20070214497A1 (en) * | 2006-03-10 | 2007-09-13 | Axalto Inc. | System and method for providing a hierarchical role-based access control |
US20080313417A1 (en) * | 2007-06-18 | 2008-12-18 | Su Yong Kim | Apparatus and method of detecting and controlling privilege level violation process |
US20110035787A1 (en) * | 2008-04-11 | 2011-02-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Access Through Non-3GPP Access Networks |
US20100010998A1 (en) * | 2008-07-09 | 2010-01-14 | The Go Daddy Group, Inc. | Document storage access on a time-based approval basis |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10817572B2 (en) | 2004-09-03 | 2020-10-27 | Open Text Sa Ulc | Systems and methods for providing access to objects and searchable attributes of objects in a collaboration place |
US10664529B2 (en) | 2004-09-03 | 2020-05-26 | Open Text Sa Ulc | Systems and methods for escalating a collaboration interface |
US11138153B2 (en) * | 2010-05-27 | 2021-10-05 | Varonis Systems, Inc. | Data tagging |
US20130339406A1 (en) * | 2012-06-19 | 2013-12-19 | Infinidat Ltd. | System and method for managing filesystem objects |
US9317511B2 (en) * | 2012-06-19 | 2016-04-19 | Infinidat Ltd. | System and method for managing filesystem objects |
US9836347B2 (en) | 2013-08-09 | 2017-12-05 | Datto, Inc. | Apparatuses, methods and systems for determining a virtual machine state |
US10705939B2 (en) | 2013-08-09 | 2020-07-07 | Datto, Inc. | Apparatuses, methods and systems for determining a virtual machine state |
US9628486B2 (en) * | 2014-10-23 | 2017-04-18 | Vormetric, Inc. | Access control for data blocks in a distributed filesystem |
EP3210156A4 (en) * | 2014-10-23 | 2018-05-23 | Vormetric, Inc. | Access control for data blocks in a distributed filesystem |
US10581858B2 (en) | 2015-04-01 | 2020-03-03 | Datto, Inc. | Network attached storage (NAS) apparatus having reversible privacy settings for logical storage area shares, and methods of configuring same |
WO2016161396A1 (en) * | 2015-04-01 | 2016-10-06 | Datto, Inc. | Network attached storage (nas) apparatus having reversible privacy settings for logical storage area shares, and methods of configuring same |
US10367824B2 (en) | 2016-03-04 | 2019-07-30 | BlueTalon, Inc. | Policy management, enforcement, and audit for data security |
US10803190B2 (en) | 2017-02-10 | 2020-10-13 | BlueTalon, Inc. | Authentication based on client access limitation |
WO2018148597A1 (en) * | 2017-02-10 | 2018-08-16 | BlueTalon, Inc. | Authentication based on client access limitation |
US10291602B1 (en) | 2017-04-12 | 2019-05-14 | BlueTalon, Inc. | Yarn rest API protection |
US10250723B2 (en) | 2017-04-13 | 2019-04-02 | BlueTalon, Inc. | Protocol-level identity mapping |
US11146563B1 (en) | 2018-01-31 | 2021-10-12 | Microsoft Technology Licensing, Llc | Policy enforcement for search engines |
US11005889B1 (en) | 2018-02-02 | 2021-05-11 | Microsoft Technology Licensing, Llc | Consensus-based policy management |
US11790099B1 (en) | 2018-02-09 | 2023-10-17 | Microsoft Technology Licensing, Llc | Policy enforcement for dataset access in distributed computing environment |
US20210240768A1 (en) * | 2020-02-05 | 2021-08-05 | EMC IP Holding Company LLC | Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace |
US11893064B2 (en) * | 2020-02-05 | 2024-02-06 | EMC IP Holding Company LLC | Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace |
Also Published As
Publication number | Publication date |
---|---|
JP5506829B2 (en) | 2014-05-28 |
CN102341809B (en) | 2015-04-22 |
JP2012520496A (en) | 2012-09-06 |
WO2010102914A1 (en) | 2010-09-16 |
US8886672B2 (en) | 2014-11-11 |
CN102341809A (en) | 2012-02-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8886672B2 (en) | Providing access in a distributed filesystem | |
US11334562B2 (en) | Blockchain based data management system and method thereof | |
AU2017352545B2 (en) | Systems and methods for digital identity management and permission controls within distributed network nodes | |
US7200869B1 (en) | System and method for protecting domain data against unauthorized modification | |
US8447728B2 (en) | System and method for storage operation access security | |
US8346952B2 (en) | De-centralization of group administration authority within a network storage architecture | |
US7827403B2 (en) | Method and apparatus for encrypting and decrypting data in a database table | |
US9325721B2 (en) | Restricting access to objects created by privileged commands | |
EP1503266B1 (en) | Zone based security administration for data items | |
US8191115B2 (en) | Method and apparatus for extensible security authorization grouping | |
US20060095698A1 (en) | Data processing method with restricted data arrangement, storage area management method, and data processing system | |
JP6932175B2 (en) | Personal number management device, personal number management method, and personal number management program | |
US20120131646A1 (en) | Role-based access control limited by application and hostname | |
EP1922625A2 (en) | Dual layered access control list | |
US8079065B2 (en) | Indexing encrypted files by impersonating users | |
US20060156021A1 (en) | Method and apparatus for providing permission information in a security authorization mechanism | |
US20060156020A1 (en) | Method and apparatus for centralized security authorization mechanism | |
US7890990B1 (en) | Security system with staging capabilities | |
JP4342242B2 (en) | Secure file sharing method and apparatus | |
Delessy et al. | Patterns for access control in distributed systems | |
US20170163652A1 (en) | Secure data corridors | |
WO2016177051A1 (en) | Security authentication method and device | |
WO2017020947A1 (en) | Document access | |
US8666945B1 (en) | Method and apparatus for utilizing securable objects in a computer network | |
Haynes | Requirements for Labeled NFS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHAURASIA, ASHISH;JUJJURI, VENKATESWARARAO;LANJEWAR, UJJWAL;SIGNING DATES FROM 20081209 TO 20081211;REEL/FRAME:022402/0052 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551) Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |