Question:

How does Acronis Files Connect (formerly ExtremeZ-IP) map the Windows security model to Macintosh-style folder permissions?

Answer:

While Windows uses access control lists (ACLs) exclusively to enforce security, the Macintosh uses any one of three different schemes, Mac-style folder permissions, UNIX permissions, or ACLs. Regardless of what scheme the Mac is using, Acronis Files Connect must map the Windows ACL to each of these Macintosh schemes in order to provide the necessary file and folder security expected by the user and/or application.

Briefly, an ACL consists of any number of access control entries (ACEs), each of which determines the access rights to the file or folder (object) for a group or user. AFP 3.2 supports ACLs as well as UNIX permissions and Mac-style permissions. ACEs can be explicit meaning they are assigned only to the file or folder in question, or they can be inherited. Your Windows administrator can set security on a folder such that it is inherited by all objects in that folder and subfolders. This practice can lead to very interesting security ramifications when viewed from the Macintosh. However, it should be understood that Acronis Files Connect will never override the security for an object, or modify it in such a way that permissions would be granted beyond those intended or that occur naturally due to inheritance.

UNIX permissions and ACLs are only accessible on the Macintosh client when the user is logged in exclusively as a domain account. That is, a user must be logged in to the Mac and Acronis Files Connect server using a domain account for which there is no local account on the Mac. The Macintosh is not able to translate from local account information to domain account information on the client. If 'unknown' appears as an object owner or group, or a valid name appears then is replaced with 'unknown', it is most likely caused by being logged in to Acronis Files Connect as guest or logged in with a domain account but using a local account on the Macintosh. This is normal behavior for Macintosh whether it is connected to Acronis Files Connect or another file server. In spite of this display issue, access to an object will still be evaluated based on the account used to log in to Acronis Files Connect.

With release 5.2 of Acronis Files Connect, all security models on Macintosh are now supported as described in the following sections of this article.

Macintosh-style folder permissions

Mapping Windows access-control lists to Macintosh-style permissions is a complicated problem for Acronis Files Connect. Windows uses access-control lists to define what rights a user has to a given file or directory. For example, Windows might define the following security information for a directory:
Owner: Administrators
Group: Domain Users
Access-Control List:
Administrators: Full Control
rob: Full Control
Domain Users: Change
Authenticated Users: Read+Write
Everyone: Read

Macintosh permissions, on the other hand, only include permissions for the owner, the group, and "world" (very similar to UNIX-style permissions). The Macintosh also has a mechanism for specifying what permissions the "current user" has (i.e., the user making the "get permissions" request to the server), and whether or not the given user has AFP "owner" access to the directory. For example, a Macintosh user who is a member of the "Domain Users" group would view permissions on the above directory as follows:
Owner: Administrators
Group: Domain Users
Owner Permissions: READ + WRITE + SEARCH
Group Permissions: READ + WRITE + SEARCH
World Permissions: READ + SEARCH
User Permissions: READ + WRITE + SEARCH
User Is Owner: NO

Similarly, a Macintosh user who is a member of the "Administrators" group would give:
Owner: Administrators
Group: Domain Users
Owner Permissions: READ + WRITE + SEARCH
Group Permissions: READ + WRITE + SEARCH
World Permissions: READ + SEARCH
User Permissions: READ + WRITE + SEARCH
User Is Owner: YES

Acronis Files Connect maps the Windows security model by building Macintosh-style permissions on the fly. When Acronis Files Connect encounters a directory, it determines the owner and group from the Windows security information. Next, it determines the current rights of the owner, group and EVERYONE accounts to the folder. Note that it is not possible for the Macintosh to determine what special permissions a user who is specified in the access control list has (such as "rob" or "Authenticated Users" in the above example).

In general, reporting permissions to the Mac this way works well. Problems arise, however, when the Macintosh user wishes to change the permissions on the Windows side. Because the Windows security model is richer than the Macintosh mechanism, it is not technically possible to generate Windows security information "on the fly" the way we generate Macintosh information from Windows information -- in other words, the reverse process of the mapping described above does not produce a complete solution.

Consequently, Acronis Files Connect attempts to preserve as much functionality for the Macintosh user as possible, while at the same time enforcing the Windows security model and preserving most of the Windows security information.

When the Macintosh user changes the permissions of a folder, it provides a new owner, new group, and/or new owner, group and world permissions. Acronis Files Connect takes this information and builds Windows security information as follows. First, if the owner is changing, it removes the old owner and removes any entries in the access-control list for the old owner's account. Next, it repeats this process for the group. Then it removes any entries in the access-control list for the EVERYONE account. Now, Acronis Files Connect assigns the owner and group, if they have changed. Next, Acronis Files Connect builds the access-control list by adding up the rights the Macintosh has provided. However, the Windows set of rights (READ + WRITE + SEARCH/EXECUTE + DELETE + CHANGE PERMISSION + TAKE OWNERSHIP) is larger than the simple Macintosh set of rights (READ+WRITE+SEARCH). Acronis Files Connect therefore maps this information using the following rules:
* If the owner is being assigned READ+WRITE+SEARCH, the owner is assigned "Full Control" in the access-control list.

* If the group is being assigned READ+WRITE+SEARCH and the group previously had these rights, their rights are preserved as they were. If the group did not have these rights, they are given "Change" permissions. Using this technique, a Macintosh user cannot assign CHANGE PERMISSION + TAKE OWNERSHIP rights to a group. However, if the NT administrator has already assigned those permissions to the group, they will be preserved.

* If the EVERYONE group is assigned READ+WRITE+SEARCH, and the EVERYONE group already had these rights, then their rights are preserved as they were. If the group did not have these rights, then they are given "Change" permissions. Using this technique, a Macintosh user cannot assign CHANGE PERMISSION + TAKE OWNERSHIP rights to EVERYONE. However, if the NT administrator has already assigned those permissions to EVERYONE, they will be preserved.

It is also worth discussing how the Macintosh "owner" permission works. Essentially, if the Macintosh has "owner" rights, the Macintosh believes it can:
* Update/change the permissions of a directory
* Specify and save the Finder view for a directory

Acronis Files Connect maps the Macintosh "owner" permission for a directory to someone having the CHANGE PERMISSION and the TAKE OWNERSHIP rights. If a user has these permissions, then they will be reported as the owner of the folder to the Macintosh.
Finally, we should discuss what happens when a Macintosh client creates a folder on the Acronis Files Connect volume. The following happens as soon as the directory is created, BEFORE THE MACINTOSH SEES THE RESULTING DIRECTORY:
The created folder is assigned the OWNER and GROUP from the thread's token. A token is generally created when you log-in to a server, and contains information about your security rights on the Windows machine. The token has several components, including an OWNER, PRIMARY GROUP, USER, GROUP LIST, and default ACL.

After the directory is created, however, the Macintosh client attempts to mimic some of the settings of the parent directory. It therefore assigns the containing folder's group to the folder and then assigns the same rights for the group and EVERYONE accounts. This can cause problems, for example, if the primary group of the user is not the group of the folder.

Finally, it should be noted that Windows allows permissions on files as well as directories. The Macintosh has no mechanism for examining these permissions. However, these permissions are enforced by Acronis Files Connect.

(Note that it is hard to determine the OWNER and GROUP for a token. Since it is only possible to have a token after you log-in, the server cannot tell an administrator what security attributes a given user would have unless the administrator provides a password. Similarly, Windows does not provide any good mechanism for viewing the GROUP of a particular file or directory. Acronis has developed some utilities that can assist administrators with these tasks. Contact Acronis support for more information.)

UNIX Permissions

Support for UNIX permissions can be enabled in release 5.2 and later of Acronis Files Connect. This provides even more compatibility with the Macintosh security model.

UNIX permissions rely on shared identity information between the client and the server. It is necessary to use domain accounts as indicated above to get full support for UNIX permissions. Since Acronis Files Connect must access Active Directory to identify users and groups used with UNIX permissions, valid account credentials for a user that can search AD are required. The credentials are entered in the Acronis Files Connect administrator on the Security tab. It is not necessary for the account used to be an AD administrator. Most accounts that are members of the 'Users' group in AD can search for the information used by Acronis Files Connect. The Acronis Files Connect administrator provides the ability to verify that the account has the search access required to support this feature.

UNIX permissions are similar to Mac-style folder permissions with the exception that permissions can be set for each file or folder individually.
Each file or folder has the concept of an owner, and a primary owning group. UNIX permissions are used to determine the kind of access the owner has to the object, the kind of access members of the primary group have to the object, and then what kind of access everyone else has to the object.

When an object is created through Acronis Files Connect by an application or user on the Macintosh, it becomes owned immediately owned by the user who created it, and full control is then granted to the owner. This allows the application or user to set further security on the object and then write data to it or create new objects in it if it is a folder. This is in compliance with BSD UNIX permissions as used by OS X. Usually at the completion of the creation process, a command will be sent from the Macintosh to Acronis Files Connect to set the final disposition of the UNIX permissions such that others may or may not be able to access the object.

When UNIX permissions are set, Acronis Files Connect adds one or more explicit ACEs to the object's ACL...one for the owner, one for the primary group, and one for everyone else. It should be noted that BSD's description of how owner, group, and everyone interact differs from how they necessarily interact on Windows. In the BSD definition, 'everyone' does not include the primary group, and the 'primary group' does not include the owner. In the Windows security model, membership is inclusive such that 'everyone' includes the primary group, and the 'primary group' may include the owner. This means that the Mac may grant everyone read access to the object and no read access to the 'primary group', and would expect a member of the primary group to not be able to read the file. When Acronis Files Connect is requested to read the file on behalf of a member of the primary group, that member will be granted read access because they are a member of 'everyone'.

It should also be noted that some decisions about access to an object are made at the Macintosh client level while others are passed down to the Acronis Files Connect server. This can be confusing because in some cases the UNIX permissions will appear to be honored according to BSD rules if the decision is made on the Mac client while at other times the access decision will be based on the description of how membership is determined by Windows.

In the above example, if the client made the decision about whether or not a member of the group could read the file, it would deny read access because the UNIX permissions returned by Acronis Files Connect would indicate that the group did not have read access. Yet if the decision is passed to Acronis Files Connect the group member would be able to read the file because Windows security would allow it.
UNIX permissions can be set through the Macintosh 'Get Info' window or by using the 'chmod' command through 'Terminal'. See the man page for 'chmod' for instructions on how to use this command.

For example, you could set the UNIX permission for file foo.txt using 'chmod' such that the owner would be granted full control, the members of the primary group would be granted read and write access, and everyone else would be granted only read access. Assuming you are the owner or otherwise have rights to change permissions on the file, you would enter:
chmod 764 foo.txt

Acronis Files Connect would add (or modify if they already exist) three explicit ACEs in the ACL for foo.txt. One would grant the owner full control, one would grant members of the primary group read and write access, and a third one would grant 'everyone' only read access.

If UNIX permissions are enabled but ACLs are not enabled, you will only be able to see and/or effect changes to the UNIX permission security entries in the ACL. While the ACL may contain other entries, they are not requested by nor returned to the Macintosh client. The other ACEs will be used during the evaluation of access rights for the requested user to the object and may or may not grant additional rights.

Group Logic recommends enabling ACLs if UNIX permissions are enabled. This provides a complete picture of how security is set for an object.

Access Control Lists (ACLs)

ACL support can be enabled on Acronis Files Connect 5.2 and later provided UNIX permissions are also enabled. ACLs provide a much finer level of security granularity than does UNIX permission or Mac-style folder permissions. For example, you can grant members of one group the right to read a file, and modify it, but not delete it while yet allowing members of another group the right to read the file, modify it, maybe execute it if it is a program, and delete it.

The following access rights can be allowed or denied for any file or folder if ACLs are enabled:

• Read data/list directory
• Write data/add file to directory
• Execute/traverse a directory (browse)
• Delete
• Append data/add subdirectory
• Delete child directory
• Read attributes
• Write attributes
• Read extended attributes
• Write extended attributes
• Read security
• Write security
• Change owner

ACL support allows the Mac client to set or get the object's ACL using the 'Get Info' window or 'chmod' in Terminal. The ACL entries can be added, deleted, and modified within the capabilities of the Macintosh tool used. The Macintosh UI has significant limitations when viewing or modifying ACLs but 'chmod' does not. You can even add inheritable ACEs to a folder using 'chmod'.

When the ACL is to be displayed on the Macintosh, the client sends requests to the server first to get the ACL, then to translate each identity found in an ACE to a displayable name. Acronis Files Connect returns the true name as found on Windows for the ACL entry. For example, if the group 'Domain Users' has access to the object, '\Domain Users' will be displayed in Leopard. This may be shortened in Tiger due to client-side display limitations. SMB, on the other hand, will show this as 'staff'. This is not a valid representation for the group as members of the 'Domain Users' may not be members of the local Macintosh 'staff' group.

Unlike UNIX permissions which only show the rights for the owner, group, and everyone, ACLs allow you to see all of the security applied to an object (assuming you have the rights to see the security information). Since you can add additional ACEs to the ACL or remove them, you can fine tune the security for any object easily restricting users in one group while allowing those in several others access to an object.

An object's ACLs can also be used to deny access rights to a group or user. Expliciit ACEs take precedence over inherited ACEs and Deny ACEs take precedence over allow ACEs. Think of the ACEs in an ACL as being in two sets, those that are explicitly added to the file or folder, and those that are inherited from its parent folder. ACEs are then ordered in each of those sets with DENY ACEs followed by ALLOW ACEs. In other words ACEs are applied as follows:

• Explicit Deny
• Explicit Allow
• Inherited Deny
• Inherited Allow

In this way you can have an ACE that is inherited from the parent folder that denies a group of users the right to delete files and still grant an individual member of that group explicit permission to delete files by adding an explicit allow ACE to the files. Likewise you could reverse the example and deny a user the right to delete files while granting that right to members of the group the user belongs to by having an explicit DENY ACE for the user to be excluded. This is the more common use for the DENY ACE feature.