A Deeper Look into Isilon Permissions
11 March 2020
As mentioned in part one of this blog series, Dell EMC Isilon uses a Unified Permission Model, which means they store the permissions for all their protocols in the same place. That place is a user token that’s generated when the user initially connects to the Isilon. Isilon will go out to all authentication providers that are configured to try and build a complete token. If you use both NFS and SMB protocols in your environment, it will attempt to go to both providers. If you use RFC 2307 and keep your Unix attributes in Active Directory (AD), then it will attempt to pull both from AD.
To better understand how these permissions work, let’s go through a scenario where we convert a single protocol environment to a multiprotocol environment. Today, we start off as an SMB-only environment that we are going to make multiprotocol by adding Unix attributes to AD (RFC 2307). In this case, your user token may look like this:
Here you can see you have a valid Security Identifier (SID) but your user identifier (UID) is 1,000,000, which means it is fake. The group identifier (GID) under domain users is also 1000000. Both of these are fake because Unix is not configured and therefore isn’t Unix provider configured. Since the token needs to be complete, Isilon makes up a fake number. Before you could access anything over NFS, we would need to add some Unix credentials. Let’s go ahead and put a UID in AD:
The next time you connect to the Isilon, your token will look like this:
Here you can see the UID has been updated to the new 222 UID; we will go ahead and add GID 513:
Now we can see that the token has been fully populated by real data, and all the fake information has been overwritten. We are in a situation where all the files on the Isilon have been written via SMB. Your files would look like this from the Isilon permissions standpoint.
-rwx------ + 1 SBOX\scotty SBOX\domain users 0 Feb 17 17:13 Document after Linux added.txt
OWNER: user:SBOX\scotty
GROUP: group:SBOX\domain users
0: user:SBOX\scotty allow file_gen_all
The key thing to look at here is the “+” after the Linux POSIX bits. What this “+” means is that the Linux permissions were approximated. When a file is written, it is saved with the protocol permissions with which it was initially written – in this case Windows access control lists (ACLs). Since there isn’t a 1-to-1 mapping from Windows ACLs to POSIX bits, Isilon must approximate how to display the permissions. If a Linux user were to attempt to access this file, the approximation wouldn’t matter because authentication will be done using SMB or SID. They only approximate them because they need to display something when listing.
Vice versa is true as well. If a file is initially written via Linux/NFS, it will have real POSIX bits and synthetic ACLs:
drwxr-xr-x 3 root wheel 21 Jan 17 07:18 Isilon_Support
OWNER: user:root
GROUP: group:wheel
SYNTHETIC ACL
0: user:root allow dir_gen_read,dir_gen_write,dir_gen_execute,std_write_dac,delete_child
1: group:wheel allow dir_gen_read,dir_gen_execute
2: everyone allow dir_gen_read,dir_gen_execute
They have to create Windows ACLs so a user can see permissions when looking in properties. If initially written in Linux, it will always authenticate via the Linux method to make sure permissions are processed currently.
To recap: When a file is written, the permissions of the protocol with which it was written is saved on disk. If written with Linux, then the POSIX bits will be real and Isilon will create synthetic ACLs mainly for display purposes. The same is true if initially written from a Windows box via SMB. The Linux POSIX bits will be approximated. However, access will always be correct because it will be done though the real permissions.
This can lead to confusion because if you are migrating from a VNX, this ia a device where permission models are kept separate. Therefore, they can be displayed differently even though they function the same.