This blog post is the 4th in a series covering basic multiprotocol concepts in Isilon OneFS. Multiprotocol data access provides unified, consistent file access across data access protocols.  Here, we’ll cover how OneFS checks file access permissions.

 

Overview

The first half of Isilon’s multiprotocol data access story is how OneFS generates identical access tokens for the Windows/SMB and UNIX/NFS sides of the multiprotocol house. File access checking is the second half of the story. When access token generation completes, the user’s actual file permissions are entirely defined by comparing the access token against permissions on the file.

 

OneFS files support two distinct states in which a file’s permissions live, but the two states still present a unified permission set. We’ll illustrate how they do this in the following sections.

 

OneFS has to present protocol-specific views of permissions so that NFS exports display mode bits and SMB shares show ACLs. How this is achieved is critical to understanding multiprotocol permissions.

 

Two conceptual differences are key to understanding Isilon file access checking:

  • Permissions state tells OneFS which permissions to look at to determine access permissions: Portable Operating System Interface (POSIX) permissions plus a Synthetic ACL, or Access Control List (ACL) permissions. The permissions state affects only a file’s access permissions behavior. The permissions state does not affect the access permissions themselves.
  • Access permissions determine whether or not a user can access a file or directory. Access permissions are based on the comparison of the user’s access token and the actual permissions..

The permissions state and the access permissions on a file or directory do not affect each other. Access permissions have to be consistent (identical) regardless of the file’s permissions state.

 

To examine file permissions, use the Isilon command line interface (CLI) to issue one of the following extended ls commands. Only the Isilon CLI can provide the full view of the files state and permissions.

  • File permissions:
    • ls –le <filename>
    • ls –len <filename>
  • Directory permissions:
    • ls –led <directory>
    • ls –lend <directory>

 

The extended ls commands reveal exactly what’s going on with access permissions. You cannot get a complete, accurate picture of a file’s access permissions by looking only on UNIX across NFS, or only on Windows across SMB. The only way to see the whole file access permissions picture is to look at the file permissions directly on the Isilon cluster using the extended ls commands. This is critical if you’re troubleshooting file access permissions issues.

 

  The following screen capture shows the difference between the

ls –al command results and the  ls –le command results.


CLI-ls-le.PNG.png

(To see a larger version, click the screen capture.)

 

You can see that the ls –al results show the standard UNIX POSIX permissions on the file, while the ls –le results are much more detailed. We’ll go into what the ls –le results mean.

“There can be only one”

In OneFS, files and directories can have only one set of permissions and can exist in only one of two states:

  • Either:

POSIX authoritative with a synthetic ACL, also called real POSIX/synthetic ACL. This is the familiar UNIX permissions mode with permission bits that provide information about the file or directory type and the permissions. The basic permission 9 bits are grouped as three 3-bit sets which contain the read, write, and execute (rwx) permissions for each class of users: owner, group, and everyone. This state also includes a synthetically generated ACL for SMB/CIFS access that reflects the POSIX permission but is compatible with SMB access.

  • Or:

ACL authoritative with approximated POSIX, also called real ACL/approximated POSIX.

 

How you manage permissions on files may need to change depending on which permissions state a file is in. The effect on permissions management can be influenced by the file’s permissions state. Whether a file’s permissions state is POSIX authoritative or ACL authoritative makes no difference to the actual access permissions.

 

The following diagram summarizes how Isilon handles file permissions in an SMB/NFS multiprotocol environment:

  • File1 is in the POSIX authoritative/synthetic ACL state.
  • File2 is in the real ACL/approximated POSIX state.

 

FileAccessChecking1.PNG.png

(To see a larger version, click the screen capture.)

The next sections explain how permissions checking works across protocols, even when a file’s native access permissions do not match the access protocol.

File 1 – what is going on

When you access a file that is in the real POSIX/synthetic ACL state using NFS, OneFS checks the standard POSIX permissions. But if you access the same file using SMB, it’s more complicated. SMB’s permissions structure is much richer than the POSIX “read, write, execute” for “user, group, everyone” structure. When a Windows user checks the permissions of a file that has the POSIX authoritative state by using the Windows Explorer Security tab, that user expects to see the file’s ACLs. But there are none: the file has only real POSIX mode bits. So how does OneFS handle this?

 

When a file is accessed over SMB, OneFS generates a synthetic ACL that’s based directly on the file’s POSIX permissions. The synthetic ACL is a direct, one-to-one correlation of the POSIX permissions to an ACL.  The synthetic ACL is not persistent: it is not stored on disk. OneFS only creates the synthetic ACL at the time the file is accessed using the SMB protocol.

 

Let’s look at the NFS side. File1 is in the real POSIX/synthetic ACL state. When you issue the ls –l or ls –al commands for File1 over NFS, you’ll see the real POSIX permissions as expected. But if you’re a Windows user looking at File1’s permissions over SMB using a Windows Explorer Security tab, you don’t want to see POSIX bits. For one thing, POSIX bits aren’t as rich as SMB ACL’s, and for another, you expect to see SMB-style ACLs for File1. OneFS accommodates Windows users’ expectations by automatically generating a set of synthetic ACLs on the fly based on the POSIX bits. The resulting ACLs emulate the POSIX permissions and look like normal ACLs. This doesn’t change the actual permissions, and it doesn’t affect how actions can be taken on File1. For example, an administrator can still use standard UNIX tools like chmod to modify File1’s permissions.

File2 – what is going on

If a file on the Isilon cluster is in the real ACL/approximated POSIX state, that real ACL is authoritative for file permissions regardless of protocol access. Accessing that file from Windows/SMB means that OneFS performs the file access check directly against the ACL as usual. In fact, you can manage the ACL permissions using the Windows Explorer Security tab directly. If you’re a UNIX user looking at the same file’s permissions over NFS, your access is still defined by that file’s real ACL. The POSIX bits don’t matter from an access check perspective, but OneFS will still need to show you the POSIX mode bits. That’s because when you issue an ls command on a file across NFS, OneFS has to return an NFS view of file permissions. But those POSIX mode bits don’t represent the file permissions: the REAL ACL does.

 

Confused yet? Keep in mind that an ACL can contain myriad separate entries. For example, you can add many UIDs, GIDs, and SIDs to define permissions if you need to. But POSIX has only three bits to work with: read/write/execute for the three permissions classes: user/group/everyone. Because there isn’t an exact match of ACLs to POSIX bits, OneFS can’t do a one-to-one mapping of permissions settings. The returned POSIX is just an approximation of a real ACL to the best of UNIX’s ability, so OneFS has to check the file access directly against the ACL as it is likely a lot more granular.

 

Let’s say that you want to examine the access permissions for the posix.txt file. The following screen capture shows how the permissions display when you look at them on the Isilon cluster using the CLI.

 

CLI-ls-le-caption.PNG.png

(To see a larger version, click the screen capture.)

When you issue the ls –le command, you can see that posix.txt is in the POSIX authoritative state and has real POSIX bits because there’s a synthetic ACL. OneFS uses those real POSIX bits for NFS file access checking, and the synthetic ACL for SMB file access checking. The synthetic ACL is not stored on disk: it’s generated on the fly on access. There can be up to three synthetic discretionary access control lists (DACLs) to represent the POSIX permissions directly.

 

Now let’s look at the ACL side. The file acl.txt permissions state is real ACL/approximated POSIX. How can you tell? Once again, by looking at the file permissions directly on the Isilon cluster, using the CLI. Take a look at the following screen capture.

 

PlusSignCaption.PNG.png

(To see a larger version, click the screen capture.)

When you issue an ls -al command on acl.txt on the Isilon cluster using the CLI, you see a plus sign following the file permissions. The plus sign indicates that the file has real ACLs and is in the real ACL/approximated POSIX state. The plus sign is the only indicator that acl.txt has real ACLs, and it shows up only on the Isilon cluster when you use the CLI. The plus sign doesn’t display if you issue ls -al on UNIX over NFS, and it doesn’t display on Windows over SMB. You must look at the file permissions using the Isilon CLI to definitively determine the file’s permissions state.

 

When a file has real ACLs, the ACLs are authoritative. Notice that, in the ls –le results for acl.txt, there are five DACL entries that make up the ACL. POSIX supports only three permissions classes: user/group/everyone. The file access permissions check is made directly against the ACL, but if you’re looking at the permissions from the NFS side, OneFS still needs to display a set of POSIX permissions: it has to. Just remember that if you see the plus sign, the POSIX permissions are only representative. POSIX permissions may look more permissive than the real ACL. Make sure that you check a file’s permissions only on the Isilon cluster using the CLI and the extended ls commands. That’s the only way to get a precise view of the exact permissions on a file.

 

chmod on POSIX files

When you issue a chmod command on POSIX files, the chmod works exactly as expected. The chmod command manipulates the POSIX bits as usual.  Since the synthetic ACL is created only on file access, it will dynamically update on access. But it will always reflect the real POSIX as a synthetic ACL.

The extended chmod command

But what if the file has Real ACLs? You can use the Windows Explorer Security tab to view and manage real ACLs directly (the preferred method), but you can also use the Isilon extended chmod command from the Isilon CLI. The extended chmod command provides additional functionality to directly manipulate a real Isilon ACL. The following extended chmod parameters enable you to directly manipulate a real ACL.

  • +a: add permissions
  • -a: remove permissions
  • =a#: rewrite a specific ACL entry

For details, type the command man chmod on the Isilon cluster.

 

The following screen capture shows a sample extended chmod command that adds permissions for the group wheel on the real ACL/approximated POSIX file acl2.txt.

 

ExtendedChmod.PNG.png

(To see a larger version, click the screen capture.)

You must use either the Windows Explorer Security tab or the extended chmod command on the Isilon cluster to reliably and definitively manage ACLs on an Isilon cluster. You can make normal POSIX permissions changes on real ACL/approximated POSIX files, but keep in mind that the resulting behavior depends on what the ACL policies are on the Isilon cluster. The same is true for managing permissions on POSIX authoritative files. The normal POSIX tools (chown and chmod) can and should be used to make permission changes to POSIX authoritative files. Changing POSIX permissions using the Windows Explorer Security tab can potentially destroy the POSIX permissions and apply a real ACL. This is why it is critical that you understand the permissions state of a file or directory tree and make the appropriate choice for the state of the file and the permissions management. This is the crux of the unified permissions model: a change on one side will always be reflected on the other side.

ACL policies management

ACL policies configure how OneFS manages permission tool interactions in multiprotocol environments. The ACL policies are global: they define how permission tools on the Isilon cluster interact and behave. The default ACL policies are sufficient for most environments. Change them only if you have a compelling reason to do so, such as a business requirement for a specific behavior on the cluster around permission management, and only if you fully understand the implications of the change.

 

The following screen capture shows the ACL Policies tab of the OneFS WebUI Protocols panel.

 

ACLPolicySettings.PNG.png

(To see a larger version, click the screen capture.)

ACL policies:

  • Do not relate to actual file permissions
  • Do not define file or directory access permissions
  • Are not related to exports or share permissions
  • Do not manage multiprotocol access
  • Do not change multiprotocol behavior
  • Do not affect access tokens
  • Can be set only on a global basis: ACL policies cannot be set on a per-access-zone basis

 

Important: Because the ACL policies change the behavior and abilities of permission tools (chmod, chown, and the Windows Explorer Security tab) throughout the system, you must fully understand the implications of changing them.

 

Any changes to ACL policies affect only the tools’ interaction and behavior going forward. That enables you to make changes in your test environment, observe the behavior, and reverse the changes if necessary.  Before you decide to set a policy that, for example, allows changing permissions on UNIX but not on Windows, make sure that you fully understand the implications of that change. Set up a test environment, make the ACL policies changes that you’re considering, and note what those changes actually do.

 

For example, disabling the setting “Allow the creation of ACLs over SMB” turns off the ability to manage permissions using Windows Explorer completely. This may or may not be what your requirement is. The default settings are designed to provide maximum flexibility in a multiprotocol environment but some fine tuning maybe required to meet a specific requirement. As with all changes, we recommend that you test and validate any changes to the ACL policies.

Takeaways

Here are some highlights:

  • File access checking is the second half of the multiprotocol data access story. A file or directory’s permissions state tells OneFS which permissions to look at to determine access permissions.
  • A file or directory can exist in only one permissions state at a time: either POSIX authoritative with synthetic ACL, or ACL authoritative with approximated POSIX.
  • The permissions state affects only a file’s access permissions behavior, not the user’s access token or the access permissions themselves.
  • Always check file permissions directly on the Isilon cluster using the CLI and extended ls –le or ls –len commands. That’s the only way to see the file’s exact, precise permissions. This critical when you’re troubleshooting permissions problems.
  • OneFS handles permissions checks according to the file or directory’s permissions state and the protocol used to access the file. The access token and the permissions themselves are not affected: only the behavior of the permissions checking tools and their interaction is determined by the permissions state.
  • You can use the Windows Explorer Security tab to view and manage real ACLs, or you can use the Isilon extended chmod command from the Isilon CLI.
  • ACL policies configure how OneFS manages permission tool interactions in multiprotocol environments. ACL policies globally change the behavior and abilities of permission tools (chmod, chown, and the Windows Explorer Security tab). Before you change ACL policies, you must fully understand the implications of changing them.

References

 

Coming soon

The next (and last!) post in this series covers the Isilon Job Engine Permission Repair job and troubleshooting.

 

Let us know

Tell us what you think of this article. Was this level of information useful? Do you have questions that you would like us to cover in future blog posts? Let us know by leaving a comment.