KR20010026229A - File access control in a multi-protocol file server - Google Patents

Abstract

PURPOSE: A method for controlling file access of multi-protocol file server is provided to control the file access between client devices using multi various access control models and multi various file server protocols. CONSTITUTION: A file server(110) is allocated for receiving a file server request(121) from a client device(120). The file server(110) decreases each request(121) and determines whether an operation requested by the request(121) is permitted. If the operation requested by the request(121) is permitted, the file server(110) is operated in one or more target files(112). The file server(110) is allocated for transmitting a file server response(122) to the client device(120). The file server(110) determines a response to each request(121), generates a response(122), and transmits the response(122) to the client device(120) which transmits the request(121). Each client device(120) is allocated for transmitting the file server request(121) to the file server(110) and receiving the file server response(122) from the file server(110).

Description

FILE ACCESS CONTROL IN A MULTI-PROTOCOL FILE SERVER}

The present invention relates to file access control of a multi-protocol file server.

In an integrated computer network, it is desirable for multiple client devices to share access to the same file. One known method is to provide a network file server for storing files that can receive and respond to file server requests from client devices. These file server requests are generated using the file server protocol, which is recognized and attached by both the file server and the client device. Since the file is stored in the file server, multiple client devices have the opportunity to share access to the same file.

In file systems used by more than one user, it is desirable to restrict access by programs to files in the file system. Restriction of access includes at least (1) user identification—determination requiring an actual user present—and (2) access control confirmation—determining which identified users are allowed to access a particular file in a particular manner. When the file system is maintained remotely from the user making the request, it is an additional aspect of the access control protocol that the request can be generated by the user accessing the file or setting access control on the file.

One problem with the known art is multiple multiple access control protocols, each corresponding to a model for access control checks, and typically a model for access control checks, respectively, associated with a particular file system. Despite the differences between these models and protocols, file servers must respond to file server requests from each user and exhibit access control verification behavior consistent with each user's model and without security violations or alarms against the user. .

For example, a commonly used first access control model is combined with a Unix operating system (or a variant thereof). This first access control model combines each file and permission for the file owner, the owner's group, and all other users. These permissions allow access (for the owner, group, or all other users) to read, write, or execute the indicated file. The first access control model is normally implemented by an auxiliary file locking protocol, NFS ("Network File System") file server protocol, which is augmented with NLM ("Network Lock Processor"). The commonly used second access control model is combined with the Windows NT operating system. This second access control model combines an ACL (Access Control List) with each file, each entry, group of users, or all users in an ACL that classifies individual users. Each entry may allow access to read, write, or execute the indicated file, or may explicitly deny access. This second access control model is typically implemented by CIFS ("Common Internet File System") protocol. However, NT devices can also use the NFS protocol by running "PC NFS", and UNIX devices can also handle POSIX ACLs. These two commonly used access control models are used to ensure that (1) permissions can be assigned to a file, (2) granularity of unique permissions can be assigned, and (3) that the user matches the permissions. It differs in important ways, including the method.

One known method of the art is to provide a multi-protocol file server that maps all security semantics to a single native operating system for the file server and uses a single native operating system to verify file access control. It is contemplated that "Samba" systems and similar mimic packages will use this known method. This known method has the disadvantage that it may result in a security error or astonishment for a client device using different security semantics than the native operating system of the file server.

Another known method of the art is to provide a multi-protocol file server that supports different types of security semantics for different files, but attempts to verify file access control for each user using the user's access control model. . It is believed that any "netware" product available from Novell will use this known method. This known method has the disadvantage that the user's access control model can vary considerably from a set of access control models for files, resulting in security errors or amazement for client devices that use different security semantics than those associated with the target file. Have

Accordingly, it is desirable to provide a method and system for implementing file security semantics between client devices using multiple, various access control models and multiple, various file server protocols. This advantage is obtained as an embodiment of the present invention in which a multi-protocol file server identifies each file with one particular access control model of a plurality of possible access control models, and implements a particular access control model for all access to the file. . When a file server receives a file server request for a file that uses the file server protocol with a different access control model, the file server is responsible for restricting access in other access control models to access control restrictions imposed by the file's access control model. Translate to control restrictions. The file server uses translated access control restrictions to restrict access to the file.

The present invention provides a method and system for implementing file access control between client devices using multiple, various access control models and multiple, various file server protocols. The multi-protocol file server identifies each file with one special access control model of a plurality of possible models and implements one special model for all access to the file. When a file server receives a file server request for a file using a different access control model, the file server translates the access control restrictions on the file to the restrictive restrictions in the other model. The file server uses translated access control restrictions to restrict access by the client device.

In a preferred embodiment, each file is assigned a user's access control model that creates the file or lastly sets an access control restriction on the file. When a user with a different access control model sets an access control restriction, the access control model for the file is changed to the new model. Files are organized in a tree organization, where each tree is defined by one or more access control models (which can define a user's ability to set access control restrictions on files in the tree). Each tree can be defined in NT-model-only format, Unix-model-only format, or mixed NT-or-Unix-model format.

1 is a block diagram of a system for implementing various access control models between client devices.

In the following description, preferred embodiments of the present invention are described in terms of preferred process steps and data structures. However, after the pursuit of the present application, embodiments of the present invention are implemented using one or more general purpose processors (or special purpose processors adopted with special process steps and data structures) operating under program control, and using such apparatus. Those skilled in the art should recognize that the implementation of the preferred process steps and data structures described does not require inappropriate experimentation or other inventions.

The invention described below can be used in connection with the invention described in the following application:

o Application Serial No. 08 / 985,398, filed Dec. 5, 1997, Andrea Bor, "Multi-Protocol Unified File-Locking", Representative Litigation No. NET-023.

This application is incorporated by reference as set forth below.

The enclosed technical appendix is the disclosure of the present invention and is incorporated by reference as set forth below.

System components

The figure is a block diagram of a system for implementing various access control models between client devices.

System 100 includes a file server 110, and a set of client devices 120.

In a preferred embodiment, file server 110 maintains file system 111 using the invention described in the following patent application:

o Serial No. 08 / 471,218, filed June 5, 1995, David Hits IT L., "How to Provide Parity to Raid Sub-Systems Using Non-Volatile Memory," Representative Litigation Number NET-004 ;

o Application Serial No. 08 / 454,921, filed May 31, 1995, David Hits IT L., “Entry in the File-System Layout”, Representative Lawsuit Number NET-005;

o Serial No. 08 / 464,591, filed May 31, 1995, David Hits IT L., "How to Assign Files to File Systems Integrated into Raid Disk Sub-Systems", Representative Litigation List No. NET-006 .

Each application is incorporated by reference as set forth below.

File server 110 is deployed to receive file server request 121 from client device 120. The file server 110 cuts down each request 121 and determines whether the operation required for the request 121 is allowed (enumerated by the client device 120 and the request 121 transmitting the request 121). One or more target files 112). If allowed, file server 110 performs operations on one or more target files 112.

File server 110 is also arranged to send file server response 122 to client device 120. The file server 110 determines a response to each request 121 (including a response instructed not to allow the requested operation), generates a response 122, and sends the request 121 ( 120, and transmits response 122.

Each client device 120 is arranged to send a file server request 121 to the file server 110 and to receive a file server response 122 from the file server 110.

Access control models

In a preferred embodiment, each client device 120 may be a Unix client device 120 or a Windows NT client device 120. Each client device 120 may use the NFS file server protocol to produce request 121, or may use the CIFS file server protocol to produce request 121. (Typically, Unix client device 120 may use Although using the NFS file server protocol and the NT client device 120 uses the CIFS file server protocol, the NT client device 120 can use the NFS file server protocol by using the PC-NFS implementation of the file server protocol. The file server 110 receives each request 121 and executes the operations required for the target file 112 listed by the request 121 (if allowed).

File server 110 supports one or more access control models, including a "UNIX PERM" access control model ("UNIX security style") and a "NT ACL" access control model ("NT security style"). .

Unix security styles use a user ID (UID) to identify users, and a group ID (GID) to identify the groups to which they belong:

o UID for owner

o GID for the owner

o Set "user" permission to allow permission to read, write, and execute files by the owning user.

o set permission to read, write, and execute files by a group of set-owning users.

o set of "other" permissions-allows permission to read, write, and execute files by all other users

The Unix security style is supported by the NFS ("Network File System") file server protocol, augmented by the NLM ("Network Lock Processor") auxiliary file-locking protocol.

NFS is a nationality-free protocol, so each NFS file server request 121 contains the UID and GID of the user making the request. By referring to the system password file (/ etc / passwd) and the group file (/ etc / groups), the UNIX client device 120 determines the UID and GID for the user at login time for the user.

In order to perform file access control using the Unix security style, the file server 110 determines whether the request 121 is from an owning user, a user of a group of owning users, or any other user. In response to this determination, file server 110 uses one of a user permission, a group permission, or another permission to determine whether to grant request 121.

NT security styles use security IDs (SIDs) to identify both users and groups.

o SID for the owner

o SID of the owner's group

o access control list (ACL)

The NT ACL includes one or more ACEs (access control entries), each containing a set of permissions and a SID indicating a user or group to apply. The NT security style provides three UNIX permissions (read, write, or execute) as well as a "CHANGE PERMISSIONS" permission, a "TAKE OWNERSHIP" permission, a "DELETE" permission, a "DELETE CHILD" permission, and other permissions.

NT security style is supported by CIFS ("Common Internet File System") protocol. NT security styles are further described in the following sections: Al. Rachel, "Internal Windows NT Security", Journal of Windows / DOS Developers (April and May 1993), and Stephen Sutton, "Windows NT Security Guide" (ISBN 0201419696).

CIFS is a session based protocol so that the NT client device 120 transmits an NT username and password to the file server 110 at the session connection time, since the SIDs for the user and group of users are determined. File server 110 may attempt to prove itself as a user or present an NT username and password to an NT primary domain controller.

In order to perform file access control using the NT security style, the file server 110 determines the SIDs for the user and the group of users so that the user generates a request 121. The file server 110 accumulates the permission given to the user from the ACE to be applied, and then deducts a permission which is specifically denied to the user. In response to this accumulation and deduction, the file server 110 determines whether to allow the ball 121.

Although preferred embodiments of the present invention are described with respect to Unix security styles and NT security styles, the present invention is directed to other access control models, such as the " POSIX ACL " access control model supported by any Unix device and any other operating system. This can be used. Without further invention or inappropriate experimentation, the concepts and features of the present invention described below may be used in place of the file server 110 supporting the " POSIX ACL " access control model or the access control model described in detail below. Accordingly, the scope and spirit of the present invention includes such a file server and its method of use.

File server 110 points to each file 112 maintained in its file system 111 to have a specific access control model of one of the plurality of access control models he supports. In the preferred embodiment, each file 112 is pointed out to use a Unix security style or an NT security style. File server 110 causes the indicated security style to make every attempt to access file 112 for each file 112. Thus, whether the request 121 is from a Unix device or an NT device, and whether the request 121 uses the NFS file server protocol or the CIFS file server protocol, the file server 110 may be responsible for the target file 112. It enforces the security style indicated for all demands 121 produced.

Access control

If the file server 110 receives the request 121 for the target file 112, and the request 121 matches the security style target file 112, the file server 110 is forced to a file (forced by the security style). Request 121 is checked for access control restrictions for 112).

Thus, file server 110 recognizes and executes at least the following environments:

o NT security style. File 112 has a corresponding set of access control restrictions (NT ACLs), which are set by client device 120 having an NT security style and using CIFS file server protocols.

If client device 120 generates a request 121 to access file 112 using the CIFS file server protocol, file server 110 enforces an NT ACL using NT security style, if possible.

If file server 110 can determine an NT user by communicating with an NT domain controller, or by referring to an NT user security ID (SID) database, file server 110 may determine an NT ACL that uses the NT security style. You can run

If file server 110 cannot determine the NT user, then the UID for the Unix user recorded in the CIFS file server protocol session is used to determine the equivalent Unix user and the NT ACL as if request 121 is from the Unix user. Run

o UNIX security style. File 112 has a corresponding set of access control restrictions (Unix firm), set by client device 120 having a UNIX security style and using the NFS file server protocol.

When client device 120 generates request 121 to access file 112 using the NFS file server protocol, file server 110 executes a Unix firm using the Unix security style.

However, the file server 110 may also receive the yugu 121 that does not match the security style for the target file 112. To the target file 112 for the non-compliant client device 120 by checking the translated set of (1) the translated user ID for the client device 120 or (2) the access control restriction for the file 112. The security server 120 may execute the security style for the file server 120. As described herein, file server 110 confirms the translated user ID for Unix security style file 112, preferably the translated user ID for NT security style file 112 ( When possible). Also, when file server 110 checks the translated access control restrictions for file 112, the translated access control restrictions are not recalculated for each request 121, but cached to file 112 for reuse. do.

Thus, file server 110 also recognizes and executes at least the following environments:

o NT security style. File 112 has a corresponding set of access control restrictions (NT ACLs), which are set by client device 120 having an NT security style and using CIFS file server protocols.

If client device 120 produces request 121 to access file 112 using the NFS file server protocol, file server 110 is coupled with client device 120 to produce request 121. To determine the UNIX user. Unix users have a UID (user ID).

In a preferred embodiment, file server 110 maps Unix users to equivalent NT users. The file server 110 translates the UID into a SID (security ID) which is a user equivalent to a Unix user. File server 110 enforces access control restrictions for equivalent NT users (SIDs).

File server 110 executes the following process to map Unix users to equivalent NT users:

o Client device 120 contacts file server 110 using the NFS file server protocol. NFS file server protocol request 121 includes a UID for a Unix user associated with client device 120.

o File server 110 looks up the UID in the Unix password file (/ etc / passwd) and verifies the Unix username for the Unix user. A Unix username is a string that can handle both letters and numbers that identify a Unix user.

o File server 110 translates the Unix username into an NT username using the selected mapping file. Similar to Unix usernames, NT usernames are strings that can handle both letters and numbers that identify NT users. If there is no such translation for a Unix username, file server 110 uses the Unix username as the NT username without translation.

In a preferred embodiment, the mapping file contains a set of records that each identify an NT user by NT user name and combine the equivalent Unix user name with the NT user name.

o File server 110 contacts the NT domain controller to determine the SID for the NT username. If no such NT user exists, file server 110 uses the selected parameters for the unmapped Unix user. In a preferred embodiment, this selected parameter is set to NT user "guest" by default.

o File server 110 contacts the NT domain controller to obtain the SIDs of all groups of which NT user is a member.

File server 110 caches the UID to SID mapping for a period of time, preferably for several hours.

In another preferred embodiment, if file server 110 cannot map a UNIX user to an NT user (e.g., if domain verification is destroyed), then file server 110 may have an NT ACL with a limited set of Unix firms. Map File server 110 determines these Unix firms in response to NT ACLs and corresponding Unix users. File server 110 enforces mapped access control restrictions (Unix firm) for the actual Unix user (UID).

File server 110 must perform dynamic permission mapping, where file server 110 maps NT ACLs to a set of Unix firms at the time the mapping is required. In a preferred embodiment, file server 110 caches the translated Unix firm with file 112. Thus, in order to verify access control restrictions, file server 110 performs static permission mapping, which maps the NT ACL to a set of Unix firms at the time that file server 110 establishes the NT ACL.

File server 110 executes the following process to obtain static permission mapping:

o File server 110 determines the NT user who is the owner of file 112 and maps NT user to an equivalent Unix user (file server 110 maps SID for NT user to UID for Unix user). ).

o File server 110 examines the NT ACL for file 112 and determines what " negative access "

o If the NT ACL for file 112 does not have a " negative access " provision, then file server 110 has a set of Unix firms with entries for " user permissions " consistent with the file access control restrictions provided by NT ACL. ) Occurs. File server 110 sets the Unix perm for "group permission" to be the same as the Unix perm for "other permission". File server 110 sets up the Unix firm for "other permissions" the same as the NT ACL entry for "all permissions".

o If the NT ACL for file 112 has a "negative access" offer, file server 110 rejects request 121.

Since the static permission mapping does not respond to the particular user producing the request 121, the file server 110 does not attempt to determine that provision of the NT ACL is for that particular user.

o UNIX security style. File 112 has a corresponding set of access control restrictions (Unix firm), set by client device 120 having a UNIX security style and using the NFS file server protocol.

If client device 120 produces request 121 to access file 112 using the CIFS file server protocol, then file NT user, coupled with client device 120, to produce request 121. The server 110 determines. NT users have a SID (session ID).

File server 110 maps NT users to equivalent Unix users. The file server 110 translates the SID into a UID which is a user equivalent to the NT user. File server 110 enforces access control restrictions (Unix firm) for equivalent Unix users (UIDs).

File server 110 executes the following process to map NT users to equivalent Unix users:

o Client device 120 initiates a CIFS session (client device 120 first contacts file server 110 using the CIFS file server protocol). Client device 120 transmits the NT username to file server 110.

o File server 110 translates the NT username into a Unix username using the mapping file. If there is no such translation for the NT username, the file server 110 uses the NT username as the Unix username without translation.

o File server 110 looks for a Unix user name in the Unix password file (/ etc / passwd) to determine the Unix user, the UID for the Unix user, the main group of the Unix user, and the main GID (group ID) for the Unix user. Check it. If there is no such Unix username in the Unix password file, file server 110 uses the selected parameters for the unmapped NT user. In a preferred embodiment, this selected parameter is set to the Unix user "nobody" by default.

o File server 110 looks up the UNIX user name in the Unix group file (/ etc / groups) to determine any other group and any other GID associated with the Unix user.

A request 121 for executing an operation on the file 112, or (b) a request 121 for executing an operation for setting an access control restriction on the file 112 may produce an expected result. File 112 has a security style set by file server 110.

When file 112 is first created, file server 110 sets the security style for file 112 the same as the security style associated with the file server protocol used to create it. (This is limited by the suppression enforced by the access control tree, described below.) Thus, if file 112 is created using the NFS file server protocol, the security style for file 112 is in the UNIX security style. Is set. Similarly, if file 112 is created using the CIFS file server protocol, the security style for file 112 is set to an NT security style.

When file 112 has a changed access control restriction, file server 110 sets the security style for file 112 to be identical to the security style associated with the new access control restriction. (This is limited by the constraint enforced by the access control tree, described below.) Thus, once the client device 120 sets a set of Unix firms for the file 112, the security style for the file 112 is Is set to the Unix security style. Similarly, if client device 120 sets an NT ACL for file 112, the security style for file 112 is set to an NT security style.

The file server 110 may receive the read request 121 or view an access control restriction on the file 112. Also, when file server 110 receives a request 121 to produce an increased change for an access control restriction on file 112, current access to file 112 before producing the increased change. Determine the control limits.

File server 110 recognizes and executes at least in the following environments:

o NT security style. File 112 has a corresponding set of access control restrictions (NT ACLs), which are set by client device 120 having an NT security style and using CIFS file server protocols.

If the client device 120 generates a request 121 to read or change the access control restrictions on the file 112 using the NFS file server protocol, then the client device 120 combines with the client device 120 to produce the request 121. The file server 110 determines the Unix user.

File server 110 executes the same process of mapping NT ACLs to a set of Unix firms as described above for the verification of file access control, with the following exception.

The file server 110 handles the translation of the access control restriction differently for the request 121 to read or change the access control restriction for the file 112, such as confirmation of the access control restriction.

Preferably, file server 110 performs dynamic permission mapping, where file server 110 maps NT ACLs to a set of Unix firms at the time the mapping is required. The NT security style is richer than the Unix security style-for example, the UNIX security style does not have a "negative access" offer. Thus, file server 110 may map the NT ACL to a set of Unix firms that appear differently for different Unix users. For example, for a file 112 whose owner is Higgs, if the NT ACL specifically provides read access to Alan but specifically denies read access to Beth, file server 110 may have different Unix firms for each of User Allen and Beth. Will provide. In combination with the access provided by the actual NT ACL, one set will allow read access by Alan's group and one set will not allow read access by Beth's group.

File server 110 executes the following process to obtain dynamic permission mapping:

o File server 110 determines the NT user who is the owner of file 112 and maps NT user to an equivalent Unix user (file server 110 maps SID for NT user to UID for Unix user). ).

o File server 110 examines the NT ACL for file 112 and determines if it is providing any "negative access".

o If the NT ACL for file 112 does not have a "negative access" offer, then a set of Unix firms with entries for "user permissions" and "other permissions" consistent with the file access control restrictions provided by the NT ACL. File server 110 occurs. File server 110 sets up a Unix perm for "group permissions" in the same way as a Unix perm for "other permissions".

o If the NT ACL for file 112 has a " negative access " provision, file server 110 attempts to determine whether to apply arbitrarily to a particular Unix user. If the file server can speak, it generates a set of Unix firms that reflect this particular file 112 and the access control restrictions currently available to this particular Unix user. If file server 110 cannot speak, it rejects request 121. (Otherwise, file server 110 may reject request 121 if there is any “negative access” provision in NT ACL.)

In another embodiment, similar to confirmation of access control restrictions, file server 110 performs static permission checking for requests 121 to read or change access control restrictions on file 112.

If the request 121 attempts to change an attribute of the file 112 that does not affect the access control restriction (such as access time or change time) for the file 112, then the access control restriction for the file 112 is enforced. The file server 110 makes these changes without making any changes.

If request 121 attempts to change something that is not all access control restrictions on file 112, as described above, file server 110 responds to the Unix firmware in response to the NT ACL on file 112. Fires a set of. File server 110 modifies the Unix firm generated as specified by request 121. If file server 110 cannot generate a set of Unix firms in response to an NT ACL on file 112, file server 110 rejects request 121.

One difference in setting access control restrictions is that for NT security style, file 112 can be specifically set to "READ-ONLY". For the Unix security style, the file is set to be read only by canceling the WRITE permission for the owner of the file 112. When the client device 120 using the CIFS file server protocol attempts to set the READ-ONLY attribute of the file 112, which is a UNIX security style, the file server 110 is responsible for the Unix firm for the file 112. The WRITE permission for the owner of the file 112 is cleared.

o UNIX security style. File 112 has a corresponding set of access control restrictions (Unix Firm), set by client device 120 having a UNIX security style and using the NFS file server protocol.

File server 110 executes the following process to map a set of Unix firms to NT ACL for display or modification of Unix perm by CIFS client device 120:

o File server 110 generates an NT ACL entry for "Owner," which provides the same access control restrictions as the UNIX firm entry for "User Permit."

o File server 110 generates an NT ACL entry for “Everyone”, which provides the same access control restrictions as the UNIX firm entry for “other permissions”.

o If possible, file server 110 generates an NT ACL entry for the actual requesting user, which provides the same access control restrictions as the Unix firm entry for the user. This step may require mapping a Unix user to an equivalent NT user using the UID-to-SID cache.

Similar to changing an NT ACL entry by a UNIX user, the request 121 (change of Unix firm by NT user) changes the attributes of the file 112 that do not affect the access control restrictions on the file 112. If attempted to do so, file server 110 makes these changes without changing the access control restrictions on file 112.

If the request 121 attempts to change something that is not all access control restrictions on the file 112, and as described above, the file server 110 responds to the NT set of reads for read 112 in response to NT. Generate the ACL. File server 110 changes the NT ACL generated as specified by request 121.

Access control subtree

In a preferred embodiment, file 112 of file system 111 is organized into a tree, having a set of branch nodes and a set of leaf nodes. One branch node of the tree is the root node, and each branch node of the tree is the root node for the subtree of the tree. In the file system 111, each branch node is a directory, and each leaf node is a file 112. The directory is in the form of a file 112 containing information about these branch nodes and leaf nodes in the subtree to be the root node.

File server 110 associates a finite set of access control models with each subtree. In a preferred embodiment where file server 110 supports the Unix security style and the NT security style, file server 110 represents each subtree as an NT-only format, a Unix-only format, or a mixed format.

NT-only format

When file server 110 represents a subtree as an NT-only format, it suppresses the creation of file 112 in a subtree for file 112 with an NT security style. File server 110 also prohibits changing the access control model of file 112 in a subtree different from the NT security style.

According to the NT security style, the new file 112 inherits NT ACL settings from their parent node. When a client device 120 using the NFS file server protocol attempts to create a file 112 in a subtree having an NT-only format, it is created by a UNIX user equivalent to the NT user who is the NT-owner of the root node of the subtree. Only file 112 can be created. (a) mapping the SID for the owner NT user to an equivalent UID; (b) store the UID in the record for file 112; And (c) the file server 110 determines whether the UNIX user making the request 121 is equal by comparing the UID with the UID of the request 121.

According to the NT security style, it is a special "DELETE" permission and a special "DELETE-CHILD" permission. If the file server 110 cannot determine whether a Unix user has these permissions, if the request 121 is not from the owner of the file 112 (the equivalent Unix user of the NT user as the owner) or the Unix user "root", Reject request 121 to delete file 112 from the NT-only format subtree.

According to the NT security style, it is a special "CHANGE-PERMISSION" permission and a special "TAKE-OWNER" permission. If the file server 110 cannot determine whether a Unix user has these permissions, if the request 121 is not from the owner of the file 112 (the equivalent Unix user of the NT user as the owner) or the Unix user "root", Denies request 121 to set any permission on file 112 in NT-only format subtree.

Unix-user format

Similarly, when file server 110 represents a subtree as a Unix-only format, it suppresses the creation of file 111 in the subtree for file 111 having a Unix security style. The file server 110 also prohibits changing the access control model of the file 111 in a subtree different from the UNIX security style. Attempts to set NT ACLs change the access control model for file 112 for NT security styles and are rejected in the Unix-only format subtree.

When a client device 120 using the CIFS file server protocol creates a file 112 in a Unix-only format, file owner of the file 112 for the UNIX user equally to the NT user making the request 121. The server 110 sets up. The file server 110 maps the SID for the NT user to the UID for the equivalent Unix user and uses the UID to set the owner of the file 112.

According to the UNIX security style, there is no "CHANGE-PERMISSION" permission or "TAKE-OWNER" permission. File server 110 always denies request 121 to set these permissions for file 112 in the Unix-only format subtree.

Mixed format

When file server 110 represents a subtree as a mixed format, it allows creation of file 111 in Unix security style or NT security style. The file server 110 does not prohibit changing the access control model of the file 111_ in the subtree for either the UNIX security style or the NT security style.

The administrator for the file server 110 may change the designation of the subtree from the first format to the second format (eg, from mixed format to NT-only format or Unix-only format). When the second format is incompatible with the first format (e.g., a subtree converted to NT-only format includes a node that is a UNIX security style), the file server (such as setting permissions for file 112) 110 converts these files 112 into an incompatible access control model. The request 121 for the file 112 that only checks for permission is identified using the access control model at the location for the file 112.

Although the present invention is described only with respect to two access control models, the present invention can be used with three or more access control models. In another embodiment, the subtree format suppresses file 112 in a subtree for one of a set of multiple access control models that is less than or equal to the set of all access control models recognized by file server 110. There are a number of possible subtree formats.

In a preferred embodiment, the root node of file system 111 is represented as a mixed format. The client device 120, which is the owner of the subtree, may change the format of the subtree by the request 121 for the file server 110; Accordingly, the client device 120 can change the subtree to have an NT-only format, a Unix-only format, or a mixed format. When a new subtree is created, file server 110 represents the new subtree by having the same format as its parent; Thus, if created in a subtree that is already a mixed format (the default), if it is created in a mixed format, an NT-only format if it is created in a subtree that is already an NT-only format, and a subtree that is already Unix-only format Unix-only format.

According to the present invention, the advantage is that a multi-protocol file server identifies each file with one special access control model of a plurality of possible access control models, and implements a special access control model for all access to the file.

While the preferred embodiments have been described herein, various modifications are possible within the spirit, scope, and spirit of the invention, which modifications will become apparent to those skilled in the art after the present application.

Claims (30)

Identifying a first file on the file server with a first security style selected from a plurality of security styles; And Executing the first security style for all access to the first file. The method of claim 1, wherein the plurality of security styles comprises a Windows NT security style. The method of claim 1, wherein the plurality of security styles comprises a Unix security style. 2. The method of claim 1, further comprising: combining the first file with a subset of files in a file system; And Defining a subset of the file to the plurality of security style security subsets, the method comprising: Attempts to set permissions in the file system tree are limited to the security subset. 5. The method of claim 4, wherein the security subset comprises a Windows NT security style. 5. The method of claim 4, wherein the security subset comprises a Unix security style. 2. The method of claim 1 including identifying the first file in a second security style corresponding to a file server request. 8. The method of claim 7, including combining the second security style with a file server request to establish permissions for the first file when the file server request is successful. 8. The method of claim 7, wherein the verifying step includes translating a first set of permissions associated with the first file in the first security style for a second set of permissions in the second security style; And the second set of permissions is as restrictive as the first set of permissions. The method of claim 1, wherein the executing step, Recognizing a first set of permissions associated with the first file in the first security style; Defining a first user type associated with the first security style; Translating the user from the second user type combined with a second security style to the first user type; And Executing a file server request from the second user type using the first user type and the first set of permissions. 12. The method of claim 10, wherein the step of translating is performed for an access control restriction applicable to the first file at the time of the step of executing. 11. The method of claim 10, wherein the step of translating is performed on an access control restriction that is applicable to the first file at a time at which the access control restriction is set. The method of claim 1, wherein the executing step, Translating a first set of permissions associated with the first file in the first security style for a second set of permissions in a second security style, the second set of permissions As limited as the first set; Executing a file server request in the second security style using the second set of permissions. 14. The method of claim 13, wherein the step of translating is performed for an access control restriction applicable to the first file at the time of the step of executing. 14. The method of claim 13, wherein the step of translating is performed on an access control restriction that is applicable to the first file at the time the access control restriction is set. A file server comprising a set of files that can use the file server, Each said file has a combined security style selected from a plurality of security styles available to said file server; And the file server executes the combined security style for all access to the file. 17. The file server of claim 16, wherein the plurality of security styles comprises a Windows NT security style. 17. The file server of claim 16, wherein the plurality of security styles comprises a Unix security style. 17. The method of claim 16, comprising a subtree of files in the filesystem combined with the plurality of security style security subsets, The file server restricts attempts to set permissions in the subtree to the secure subset. 20. The file server of claim 19, wherein the security subset comprises a Windows NT security style. 20. The file server of claim 19, wherein the security subset comprises a Unix security style. 17. The file server of claim 16, wherein the file server is capable of changing the security style associated with the file corresponding to a file server request. 23. The file server of claim 22, wherein when the file server request is successful, the file server can change the security style associated with the file corresponding to the file server request. 23. The system of claim 22, wherein the file server is capable of translating a first set of permissions associated with the file in a first security style for a second set of permissions in a second security style, The set is as restrictive as the first set of permissions. A file server having a plurality of files, the data structure associating a security style with each of the files, wherein the security style is selected from a plurality of security styles available to the file server. 26. The data structure of claim 25, wherein the plurality of security styles comprises a Windows NT security style. 26. The data structure of claim 25, wherein the plurality of security styles comprises a Unix security style. A file server having a plurality of files and a security style associated with each of the files, wherein the security style is selected from a plurality of security styles available to the file server, the data structure representing a security subset of the plurality of security styles. A file server associated with the subtree of the file available to the file server. 29. The data structure of claim 28, wherein said security subset comprises a Windows NT security style. 29. The data structure of claim 28, wherein said security subset comprises a Unix security style.