No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

File Access and Protocols Feature Guide 11

OceanStor 18500 V3 and 18800 V3 Mission Critical Storage System V300R003

This document describes the implementation principles and application scenarios of the NAS feature. Also, it explains how to configure and manage NAS.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Overview

Overview

This section introduces the user mapping mechanism used during cross-protocol (CIFS-NFS) share access.

CIFS-NFS Cross-Protocol Share Access

The 18500 V3/18800 V3 allows users to share a file system or quota tree using NFS and CIFS at the same time. Different clients, such as Windows clients (CIFS), Linux clients (NFS), and Mac OS X clients (CIFS or NFS) can access a file system or quota tree simultaneously. Since Windows, Linux, and UNIX adopt different mechanisms to authenticate users and control access, the 18500 V3/18800 V3 manages user mapping and permission control of different operating systems in a unified manner, protecting the security of CIFS-NFS cross-protocol access.

  • If a CIFS user attempts to access a file or directory on the 18500 V3/18800 V3, the 18500 V3/18800 V3 authenticates local or AD domain users in the first place. If the UNIX permission (UNIX Mode bits, or NFSv4 ACL) has been configured for the file or directory to be accessed, the CIFS user is mapped as an NFS user based on preset user mapping rules during authentication. Then the 18500 V3/18800 V3 performs UNIX permission authentication for the user.
  • If an NFS user attempts to access a file or directory that has NT ACL on the 18500 V3/18800 V3, the NFS user is mapped as a CIFS user based on the preset mapping rules. Then the 18500 V3/18800 V3 performs NT ACL permission authentication for the user.

CIFS-NFS Cross-Protocol Access Permissions

If permission types of a file or directory and a client that attempts to access the file or directory mismatch, CIFS-NFS cross-protocol access is required. You need to map the permission of the file or directory so that it can be displayed by the client.

  • NFS client accessing a file or directory with the NTFS permission

    When an NFS client checks the NTFS permission that a file or directory has, the client can obtain the UNIX permission mapped from an NT ACL. The NFS client displays as many permissions as possible but the actual permissions are determined by the NT ACL. For example, the NFS client shows that all users have read, write, and execute permissions, but one of the users may only have the write permission.

  • CIFS client accessing a file or directory with the UNIX permission

    When a CIFS client checks the UNIX permission that a file or directory has, the UNIX permission is mapped into three ACEs for the CIFS client. The three ACEs are for the owner, owner primary group, and everyone of the file or directory respectively. The NT ACL is displayed only but not used to control actual operation permissions.

Table 4-1 shows how permissions convert among UNIX Mode bits, NFSv4 ACL, and NT ACL.

Table 4-1  Permission conversion among UNIX Mode bits, NFSv4 ACL, and NT ACL

File Permission

Permission Conversion

The file or directory only has valid UNIX Mode bits.

  • One ACL is mapped based on UNIX Mode bits when an NFS or CIFS client sends a request to read an ACL.
  • If an NFSv4 client sends a request to set an ACL, an NFSv4 ACL takes effect and UNIX Mode bits are mapped based on the NFSv4 ACL.
  • If a CIFS client sends a request to set an ACL, an NT ACL takes effect and UNIX Mode bits with the maximum permissions are mapped based on the NT ACL.

The file or directory has a valid NFSv4 ACL or NT ACL.

  • NFS clients use the chmod command to change permissions. The NFSv4 ACL or NT ACL is abandoned and UNIX Mode bits take effect.
  • NFS clients use the chmod command to add or remove SUID/SGID/STICKY. The NFSv4 ACL or NT ACL is abandoned and UNIX Mode bits take effect.

The file or directory has a valid NFSv4 ACL.

  • If an NFS client sends a request to read UNIX Mode bits, UNIX Mode bits (mapped based on the NFSv4 ACL) of the storage system are returned directly.
  • If a CIFS client sends a request to read an NT ACL, an NT ACL is mapped based on UNIX Mode bits of the storage system.
  • If a CIFS client sends a request to set an NT ACL, the NFSv4 ACL is abandoned and the NT ACL takes effect. UNIX Mode bits are mapped based on the NT ACL.

The file or directory has a valid NT ACL.

  • If an NFS client sends a request to read UNIX Mode bits, UNIX Mode bits (mapped based on the NT ACL) of the storage system are returned directly.
  • If an NFSv4 client sends a request to read an NFSv4 ACL, an NFSv4 ACL is mapped based on UNIX Mode bits of the storage system.
  • If the NFSv4 client sends a request to set an NFSv4 ACL, an NT ACL is discarded, an NFSv4 ACL takes effect, and UNIX Mode bits are mapped from the NFSv4 ACL.

CIFS-NFS Cross-Protocol User Mapping

Windows systems (CIFS) and Linux systems (NFS) use different mechanisms to identify and authenticate users:

  • Windows systems use security identifiers (SIDs) to identify users. SIDs apply to all users, user groups, services, and computers in the systems. Regarding authentication, CIFS supports NT ACLs.
  • Linux systems use user identities (UIDs) and one or more group identities (GIDs) to identify users. One user belongs to one user group at least. Regarding authentication, NFS supports diversified security control mechanisms such as UNIX Mode bits and NFSv4 ACL.

During CIFS-NFS cross-protocol share access, users using different protocols must be mapped based on user mapping rules for user authentication and precise permission control.

The timing of user mapping is as follows:
  • When a CIFS client accesses files or directories with the NFSv4 ACL or UNIX Mode bits permission, a user mapping occurs. The user will have both the permissions before and after the user is mapped.
  • When an NFS client accesses files or directories with the NT ACL permission, a user mapping occurs. The user will have both the permissions before and after the user is mapped.
  • Cross-protocol permission editing changes permission types. For example, users are mapped when an NFS client accesses a file or directory that has the NT ACL permission. If the NFS client runs the chmod command or sets the NFSv4 ACL to change the permission of the file or directory, users are not mapped when the NFS client accesses the file or directory after the change. That is, users' permissions remain unchanged.
    NOTE:
    You are advised not to edit permissions across protocols, avoiding permission type changes.
  • When the parent directory has the inheritable NT ACL permission, the files or directories created no matter on an NFS client or a CIFS client will have the NT ACL permission by default. In this case, if the NFS client accesses files or directories, a user mapping will always occur. That is, the user will have both the permissions before and after the user is mapped. When the parent directory does not have the inheritable NT ACL permission, the files or directories created no matter on an NFS client or a CIFS client will have the UNIX Mode bits permission. In this case, if the NFS client accesses files or directories, no user mapping occurs. That is, the user's permission remains unchanged.
  • If mappings are changed on CIFS clients, the change takes effect after CIFS connections are disconnected and next re-authentication is performed.
  • User mappings on NFS clients are cached and expire after four hours by default. New user mappings and user information changes take effect after the cached data expires.

User mapping rules specify the mappings among different user accounts. The user mapping rules can be saved in a local database or managed in the AD domain in a centralized manner. A user mapping rule includes the mapping type, original user, mapped user, and mapping priority. If a user matches multiple mapping rules, it is mapped based on the rule with a higher priority. If the rules have the same priority, the user is mapped based on the rule that is configured the earliest.

A user mapping process is as follows: (Local mapping of a storage system is used as an example.)
  • NFS-CIFS user mapping: An NFS user is authenticated by UID on the service end. When a user mapping occurs, the user name to which the UID corresponds will be queried in the sequence of the local host, LDAP domain, and NIS domain. Based on the queried user name and the local mapping, the user name, SID, and the owning group of the mapped user will be queried.
  • CIFS-NFS user mapping: A CIFS user is authenticated by SID on the service end. When a user mapping occurs, the mapped user will be queried based on the user name to which the SID corresponds and the local mapping. Then the UID to which the mapped user name corresponds and its owing group will be queried in the sequence of the local host, LDAP domain, and NIS domain.
NOTE:
You are advised not to configure the same UIDs or user names in the local host, LDAP domain, or NIS domain. If the same UIDs or user names exist, the user mapping results will not be the expected results.
Translation
Download
Updated: 2018-07-19

Document ID: EDOC1000084098

Views: 25036

Downloads: 72

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next