Skip to main content

Fusion File Share Security Modes

This document discusses Fusion support for ACLs to help you configure your deployment. Although you can control access to a share via share permissions (see section 6.4 of the Fusion File Share server manual), it’s important to understand the security modes available with Fusion in order to implement ACLs. These options are specified in the share section (security = windows does not need to be specified since it is the default):

  • security = none
  • security = windows
  • security = posix

None security mode​

In this mode any users get access to any file/directory. Similar to FAT, there is no security descriptor so there is nothing to evaluate. This mode works well if you want to restrict access using per-share permissions only (section 6.4 of the Fusion File Share server manual). For example, to make share to be read-only for everyone, security can be set to none and share permissions set to "everyone:read" in the share section. In this case security descriptors are not evaluated, and this should speed up operations on a share since extra checks are not performed.

Windows security mode​

This is the default mode. Fusion is usually deployed in an enterprise environment where authentication is done by evaluating SIDs provided by the Windows client.

note

Unlike Samba, Fusion does not require any mapping of the SMB user to a Unix user – so the windows security mode can function without any POSIX references.

The windows security mode for Fusion uses Windows ACLs to authorize the user’s access to files/directories. File access is based on user identity which is the list of SIDs, originally provided by the Domain Controller as a part of the Kerberos authentication process, and used in the SMB2 SESSION_SETUP exchange between SMB client and SMB server. In windows security mode the Windows Security Descriptor (ACLs) is saved in the extended attribute of a file or directory. Therefore, support for extended attributes is required for this mode. However, if support for extended attributes is not provided then the following occurs:

  • First Fusion attempts to evaluate the Windows Security Descriptor (ACLs) from the extended attribute
  • If it is not found (which is the case for file systems mounted without extended attribute support), Fusion moves to the parent directory and tries to get a Windows Security Descriptor from it. If it is found, Fusion evaluates the ACEs that can be inherited
  • If the parent directory’s security descriptor is not found, Fusion moves to the next parent and so on, continuing until the share root.
  • If the share root does not have a Security Descriptor in the extended attribute, Fusion then takes POSIX permissions of the share root and builds a Windows ACL from it: Owner/Group/Others (Others are converted to ‘Everyone’ group). This ACL containing three ACEs is used for the access check.

Please note this mode does not utilize any UID or GID values. It’s also worth noting that in cases where extended attributes are not supported, the ACL will be the same for all files/directories because the last step (above) will result in Fusion taking POSIX permissions from the share root and building the ACL. So, if the share root is set to rwx|rwx|rwx, then everyone will be able to read/write to any files/directories. If extended attributes are not supported, it is important to consider share root permissions when using windows security mode – for example, write access from Others should at least be removed (775).

POSIX security mode​

In posix security mode the Windows ACLs are not saved and authorization of a user’s access to files/directories is performed using POSIX permissions based on UID/GID values obtained during the authentication phase. If the UID is not available (for example AD does not have RFC2307 attributes uidNumber, gidNumber), then any access to file system objects is denied because Fusion is unable to obtain a user identity to compare with POSIX permissions. But if UID is available, then exactly like in POSIX, Fusion does the following:

  • First, Fusion checks if UID matches with file UID
  • If there is a match, Fusion uses owner rwx bits to check access
  • If there is not a match, Fusion compares GID with Group ID of the file and uses group rwx bits to check access
  • Finally, if neither UID or GID matches, others rwx bits are used to check access

Unlike the windows security mode, there is no inheritance for posix security mode. Additionally, you cannot set Windows ACLs.