Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Apple > Operating Systems

  • Print
  • + Share This
This chapter is from the book

Using POSIX and ACLs

To control file- and folder-level access to information on the SAN volume, you have two options:

  • Use the Xsan Admin or Server Admin to set POSIX permissions.
  • Use Xsan Admin or Mac OS X Server’s Server Admin application to apply a full set of access control list restrictions.

Standard Portable Operating System Interface (POSIX) permissions let you control access to files and folders based on three categories of users: Owner, Group, and Everyone. While these permissions give you adequate control over who can access a file or a folder, they lack the flexibility and granularity that many organizations require when dealing with elaborate user environments.

This is where ACLs (Access Control Lists) are handy. An ACL provides an extended set of permissions for a file or folder and allows you to set multiple users and groups as owners. In addition, ACLs are compatible with Windows Server 2003 and Windows XP, giving you added flexibility in a multiplatform environment. This makes it easy to set up collaborative environments featuring smooth file sharing and uninterrupted workflows, without compromising security.

An ACL comprises a list of Access Control Entries (ACEs), each specifying the permissions to be granted or denied to a group or user and how these permissions are propagated throughout a folder hierarchy. Apple’s ACL model can control file and folder access using 13 permissions divided into three categories.

Understanding the ACL Use Model

The ACL use model is centered around access control at the folder level, with ACLs applied to files as the result of inheritance. Folder-level control defines which users have access to the contents of a folder, and inheritance defines how a set of permissions and rules pass from the container to the objects within it.

Without this model, administration of access control would quickly become a nightmare. You potentially would have to create and manage ACLs on thousands or millions of files.

In addition, controlling access to files through inheritance frees applications from maintaining extended attributes or explicit ACEs when saving a file because the system automatically applies inherited ACEs to files.

Implementing ACLs

To restrict user access to specific items on a SAN volume, you can use Xsan Admin or Server Admin to adjust permissions using ACLs. ACLs are enabled by default on a new Xsan volume. However, you would use Xsan Admin to enable or disable ACLs depending on your preference for management. If you decide to implement ACLs on your SAN instead of the more generic POSIX permissions, you should ensure that all of your SAN clients are bound to the same directory. For example, if you are going to have both Windows and Macintosh clients on your SAN, you must bind them both to Active Directory or Open Directory, and so on.

Refer to the following chart to confirm that you have a compatible version of Xsan running on your clients. You will notice that you will need at least Xsan 1.4.2 running on your Macintosh client to be compatible with Xsan 2.

Xsan 2 Compatibility

Controller

Client

Compatible

Xsan 2

Xsan 2 (Mac OS X v10.5)

Yes

Xsan 1.4.2 (Mac OS X v10.4 or v10.5)

Yes

Xsan 1.4—1.4.1

No

Xsan 1.3 or earlier

No

StorNext FX 1.4 or 2.0

Yes

StorNext FX 1.3

No

StorNext FS 2.8—3.1.2

Yes

Xsan 1.4 or earlier

Xsan 2

Yes

StorNext FS 3.1—3.1.2

Xsan 2

Yes

StorNext FS earlier than 3.0.2

Xsan 2

No

To assign permissions using Xsan Admin, follow these steps:

  1. Ensure that ACLs are enabled on the volume.
  2. In Xsan Admin, confirm that the volume is mounted on at least one client by choosing Mounts in the SAN Assets list. Mount a volume, if necessary.
  3. In the SAN Assets list, choose File Management.
  4. Select a SAN volume.
  5. Select the file or folder you want to protect and, from the Action (gear) pop-up menu, choose Set Permissions.
  6. Click the Add (+) button to add a user or group to the ACL (Access Control List) or POSIX permissions.
  7. If you need to set the permissions for a different folder or file, select the new folder or file and choose Set Permissions, or Control-click the file or folder name in Xsan Admin.

    If you are unable to set the ACLs on the folders of the mounted volume, be sure that you have completed step 1 and that ACLs have been enabled on the volume.

You might find it more convenient to set permissions on multiple folders or files using Server Admin, available online in the Server Admin tools at www.apple.com.

Using POSIX and ACL Best Practices

Xsan Admin and Server Admin both refer to standard UNIX-style permissions, user, group, and other, as POSIX permissions. While access control lists technically are part of the POSIX standard, they are referred to in Server Admin and Xsan Admin as ACLs.

Permissions are searched in order from top to bottom. During that search, ACLs take precedence over POSIX permissions, but only because they are above user, group, and other. Mac OS X does not search all permissions for a match, but searches, from top to bottom, until a match is found. Once a match is found, the search is stopped and will not continue.

Utilizing ACLs gives administrators finer control over the ways permissions are applied to files and folders. Refer to Apple Training Series: Mac OS X Server Essentials (Peachpit Press, 2005) for more information on the specific options available for an access control entry.

The best practice for assigning ACLs and POSIX permissions is to avoid collisions. If you set an ACL to allow group access to a folder, make the POSIX group and related permissions the same. By doing so, you won’t cause problems with applications or operating systems that don’t understand access controls.

Implementing ACLs with Affinities

When implementing ACLs on a volume, you can attain an additional level of storage control by assigning affinities to the folders on which ACLs have been applied.

For example, assume you want to ensure that all newly ingested video is saved to a specific volume folder and you already have assigned ACLs so that only users in the Ingest group may save files to that folder. Therefore, only the users responsible for ingesting the video can write to that folder, and when those users save video to the volume, they can save only to that specific folder. Because that folder already had an affinity that links it to a specific affinity tag (storage pool), you can use ACLs to control some users’ access to the specific affinity tag that best suited their workflow. If you did not have ACLs on that folder, you would have to trust the user to know which folder to use and to use that folder exclusively.

If you have implemented ACLs on that specific folder for specific users and groups but do not have affinities assigned to that folder, the data will be saved to storage pool(s) based on the volume’s allocation strategy. You’ll learn more about this in Chapter 5.

  • + Share This
  • 🔖 Save To Your Account