File Storage NAS:SMB ACL for File Storage NAS

Default root directory permissions

• Design rationale for default permissions

  • The SYSTEM and Administrators ACL entries align with Windows NTFS permissions to ensure that applications requiring administrator privileges can run correctly. After you integrate with RAM, this also lets you grant administrator privileges to a super admin.

  • The CREATOR OWNER permission enables inheritance, which also aligns with Windows NTFS permissions.

  • You can configure SMB ACL settings to set Allow Anonymous Access to Off. This prevents access by the Everyone identity and allows only domain-authenticated users to access the file system.

• Compatibility with existing user habits

  • To support users who do not use an AD domain, the Everyone identity is granted Full Control of files and folders created before the AD feature is enabled. This ensures that these users are not affected. Users without an AD domain can mount the file system as Everyone over the NTLM protocol and access content owned by Everyone.

  • Files or folders created by a new AD user do not inherit permissions from Everyone. Therefore, users without an AD domain cannot access these new resources. Only the creator and administrators can access them.

  • AD users can access files and folders created by users without an AD domain (that is, as Everyone).

SMB ACL features

Mounting with multiple identities not supported

Break-glass access

If a malicious user removes administrator and other user permissions, making files or folders inaccessible, you must mount the file system with an administrator identity to restore their permissions.

Cygwin integration

Cygwin provides a POSIX-compatible environment that runs on Windows for running POSIX applications. After you enable SMB ACL, user security identifiers (SIDs), group SIDs, and Windows discretionary ACLs (DACLs) are translated into POSIX user IDs (UIDs), group IDs (GIDs), and POSIX ACLs in Cygwin. For more details on this translation, see Cygwin ntsec.html.

• Add the noacl option to /etc/fstab as shown in the following figure.

  When the noacl option is added, Cygwin does not perform complex ACL translations. Instead, it applies a default mode to new files and folders. The USER and GROUP are set to the username and group of the current Windows logon user. The basic rules are as follows:

  • The default mode, UID, and GID for folders is 755.

    drwxr-xr-x 1 cat Domain Users 0 Jul 25 06:18 dir

  • The default mode, UID, and GID for files is 644.

    -rw-r--r-- 1 cat Domain Users 0 Jul 25 06:42 file

  • The mode for files can be 644 or 444.

    If the mode is 444, the file has the DOS Read-only attribute set. The noacl option only translates the file's DOS Read-only attribute.

  • The chmod command cannot change folder permissions, but it can change the file mode to 644 or 444.

  • The chown and chgrp commands have no effect.

  • The getfacl and setfacl commands are not supported.

  • Because folder permissions on the client always display as 755 and file permissions display only as 644 or 444, the client might indicate that access is allowed, but the server will deny the request.

• Use the acl option in /etc/fstab

  By default, an SMB file system is mounted with Everyone permissions, which corresponds to OTHER in Cygwin. When creating a file or folder, Cygwin behaves like Linux and automatically runs a chmod operation to set the default mode. Because the default OTHER permission for folders is r-x and for files is r--, Everyone only has r-x or r-- permissions. As a result, Everyone cannot create new files in new folders, and new files are read-only for Everyone.

  Therefore, we strongly recommend using the noacl option instead of the acl option when working with Cygwin.

AD and ACL on Linux systems

• When you mount a file system on Linux by using mount -t cifs, you can specify the domain user identity for mounting, as well as the file GID, UID, file mode, and directory mode.

• When you use the file system, the client performs basic POSIX permission checks based on the mounted UID, GID, and the logged-in user's identity.

• On the file server, regardless of the Linux user's UID or GID, operations map to the corresponding domain user identity. The Linux root user does not have administrator privileges; it has only the permissions of that domain user. Linux permission commands such as chmod, chown, chgrp, getfacl, and setfacl have no effect.

For more information, see Mount and use an SMB file system as an AD user on a Linux client.

How it works

File Storage NAS supports user management and file system access control using an AD domain controller located in your virtual private cloud (VPC) or on-premises data center. This integrates user authentication and access control for hybrid cloud environments. The SMB service for File Storage NAS uses Kerberos to authenticate AD users against your AD domain controller, whether it is deployed on-premises or on Alibaba Cloud. Users can connect to and access an SMB file system as a domain user from a domain-joined Windows or Linux server. The file server recognizes the user's domain identity to enforce directory-level and file-level access control.

The following process outlines how identity authentication and access control work with SMB ACL:

1. Generate a keytab file. For more information, see Join an SMB mount target to an AD domain .

2. Enable the SMB AD ACL feature and upload the keytab file to join the SMB mount target to the AD domain. For more information, see Step 2: Upload the keytab file.

   After the keytab file is uploaded, its information is saved to the File Storage NAS file system. The SMB mount target is now joined to the AD domain, and you can mount and use the SMB file system as an AD user. For more information, see Mount and use an SMB file system as an AD user on a Windows client or Mount and use an SMB file system as an AD user on a Linux client.

3. Authenticating users and controlling access from the client.

   When a user attempts to connect to the SMB file system from a VM in a VPC or an application in an on-premises data center, the system first validates the connection by using a permission group. The permission group controls client connectivity and access based on its rules. Then, user authentication and access control proceed as follows:

   1. After a connection to the file system is established, the client and server negotiate an authentication protocol over SMB.

   2. The file server checks the file system's configuration to verify that Kerberos authentication is enabled.

   3. The client sends a request to the AD domain controller (in your VPC or data center) to access the Alibaba Cloud file system service.

   4. The AD domain controller authenticates the user, encrypts the user's information with the service account key for the file system service, and returns the encrypted information to the client.

   5. The client sends the encrypted user information to the SMB file server in an SMB Session Setup request.

   6. The file server decrypts the user information using the keytab file provided for the file system.

      Note

      All subsequent access requests within this session are authorized as this user.

   7. If authentication is successful, the file server returns a success response to the client. Otherwise, the file server denies the Session Setup request.

   8. The application sends file access requests (such as read, write, and others) to the file server.

   9. The file server returns the access result to the client.

      The file server enforces access control. Based on the user information in the session and the ACL permissions configured on the directory or file, the server either allows or denies access.