Understanding Permission Types in Multiprotocol Migrations
Steve Leeper, NAS Pre-Sales Systems Engineer
Understanding Permission Types in Multiprotocol Migrations
Imagine a planning meeting in which the discussion taking place relates to an upcoming cross-vendor NAS migration. Perhaps the incumbent’s offering is being replaced for business reasons or there is simply an architectural change being made due to the changing needs of the enterprise. Regardless of the reason, going down the list of items to be accounted for in the discussion you might see something high level like the following:
- Discuss SMB content…check
- Discuss NFS content…check
- Soon the meeting comes to a point where the shared access multiprotocol datasets are discussed. If the complexity of cross-vendor multiprotocol migrations is known, everyone begins looking at their shoes. There might even be one lucky soul whose cell phone happens to ring so that they can run out of the room.
If one is not aware of the complexity involved in a cross-vendor shared access multiprotocol migration they might plunge quickly into the effort without realizing what lies ahead. Note, in this discussion we are defining a shared access multiprotocol dataset as a dataset which is accessible by SMB and NFS clients simultaneously. For example, simply provisioning “DirectoryA” over an SMB share while other content such as “DirectoryB” is provisioned over an NFS export is not considered shared access multiprotocol as there are two separate and distinct paths and rules governing access to the underlying data. On the other hand, if “DirectoryA” has both an SMB share and an NFS export assigned there will be access by both Windows and Linux/Unix clients simultaneously which is true shared access multiprotocol.
If you’ve never been involved with one of these types of migrations you might ask why a NAS migration that includes datasets provisioned simultaneously over SMB and NFS is so difficult? Many times there is an assumption that there is a standard governing how NAS vendors implement multiprotocol support into their products. After all, the NAS device provides access to NTFS content over the SMB protocol as outlined in the SMB2/3 specification (see SMB spec). Similarly, access to UFS/ext/XFS/btrfs, etc… filesystems content via the NFS protocol is governed by IETF standards (see RFC-1813 for NFSv3 and RFC-3530 for NFSv4). Surely there must be an industry specification or IETF RFC that governs shared multiprotocol access, right? Unfortunately, the answer to that question is “no” – there simply is no common industry specification or standards body that provides any type of guidance in this area.
Square Peg and Round Hole
Since no standards or specifications exist to govern implementations of shared multiprotocol access the vendor community is left to design their own solutions. These solutions provide the functionality required by their customers in a manner that is the most efficient given various architectural limits within each product design. Given this lack of a standard, each NAS device vendor has a different methodology for managing the separate permission models associated with the file systems accessed over the SMB and NFS protocols. Vendor A might attack the problem by storing both NTFS and NFS permissions separately. Vendor B’s approach might be to store one set of permissions and synthetically generate permissions relating to the alternative environment along with usermapping. Vendor C might decide to implement a unified model wherein both NTFS and POSIX permissions are merged into one set of “uber permissions”(if you will). This begs the question of how a multiprotocol migration might work when the source and destination systems are from different vendors. How does one take data secured via the “square peg” model of permissions storage from one vendor and migrate that to the “round hole” model used by a different vendor?
In the context of Datadobi’s DobiMigrate NAS migration software the dilemma of migrating shared access multiprotocol data is handled by leveraging the multiple protocol components within the software stack. As a quick review, DobiMigrate is composed of the following components:
- DobiMigrate Core (the “brains” of the migration engine and controls the proxies)
- DobiMigrate SMB Proxy (the component which copies data presented via SMB shares)
- DobiMigrate NFS Proxy (the component which copies data present via NFS exports)
There is always a single DobiMigrate Core while any number and mixture of SMB and/or NFS proxies might be present – the specifics of the migration environment will determine the actual deployment details.
Two Protocols, One Dataset
During a migration involving multiprotocol accessed datasets all three DobiMigrate components work in concert to copy not only the file content/data but also the all-important metadata which includes the permissions assigned. DobiMigrate allows the migration administrator to specify the use of multiple proxy types during the setup of a migration path. Not only can the administrator specify to use both SMB and NFS proxies but the order in which the proxies are used can be specified (internally, we call this ‘multi-pass’ since both proxies are being used to make multiple passes against the common dataset). Once the migration is started DobiMigrate will, if instructed to do so, use both types of proxies with the first proxy type copying data plus metadata while the second proxy type will be invoked to execute a metadata-only copy. This metadata copy will include the permissions for the second type of protocol. For example, if the multi-pass option is set to “SMB then NFS” DobiMigrate will use the SMB proxy to copy the data/file content plus the NTFS metadata including permissions to the destination. Once the file + metadata copy has completed for a given file by the SMB proxy the DobiMigrate Core will instruct the NFS proxy to execute a metadata only copy against the same file which will copy the POSIX permissions to the destination platform. DobiMigrate’s migration engine has automated these copy processes and thereby eliminated the “prison work” involved with writing all the Robocopy/EMCopy/rsync scripts that would typically be required.
Display vs Effective Permissions
As both proxy types are being used during the migration it is important to understand the impact of copying the permissions between two different NAS vendor multiprotocol implementations. This is where the differences between display permissions and effective permissions can come into play. For example, perhaps we are executing a migration wherein the NAS vendor implements multiprotocol security in a fashion dictating that only one set of permissions will be stored for a given file system object (FSO). Those permissions can either be NTFS permissions or NFS POSIX mode bits – but not both. If a given FSO is secured via NTFS permissions then we must consider the difference between viewing access permissions (ie, the display permissions) vs the evaluation of permissions (ie, effective permissions) which determine whether access to the requested FSO is allowed.
If we were to log into an SMB client and view the permissions for a given file/directory we would see the appropriate permissions as stored in the NTFS security descriptor for that object. These are the effective permissions for this FSO. Conversely, if we were to log into a Linux client and view the permissions for the same file/directory we would see display permissions as generated by the NAS appliance. If we took the step of attempting to access the file our Linux UID/GID would most likely be mapped to an equivalent AD SID (Security Identifier) and access would then be determined based on the presence of the mapped SID within the NTFS security descriptor (which contains the ACLs and the ACEs within those ACLs). The NFS POSIX permissions that are listed are informative but, in this environment, are not the actual governing permissions. For this reason, it’s important to note that the display permissions associated with the non-governing security model can be different than the effective permissions. When DobiMigrate is leveraging both types of proxies the permissions being copied can be affected by whether the proxy can see display or effective permissions – and this depends on the underlying implementation employed by the vendor. The end result can be that behavior on the destination platform can be different from the source platform when executing a cross-vendor migration.
Ultimately, when conducting a cross-vendor shared access multiprotocol NAS migration you’ll want to build time into the project plan to execute testing on your destination platform. With DobiMigrate’s automation and multi-pass capabilities you don’t have to waste time writing scripts using various tools like Robocopy and rsync. That will allow you to evaluate the behavior of the security as applied on the destination platform and ensure your users and applications will have appropriate access to all the shared access multiprotocol content.
For more details and an example check out this whitepaper