- Controlling Client Access
- Mounting and Unmounting an Xsan Volume
- Moving a Client to a Different SAN
- Controlling User Access
- Using POSIX and ACLs
- Managing Home Folders
- Setting SAN User and Group Quotas
- Understanding Xsan Quotas
- Combining Xsan Controllers and StorNext Clients
- What Youve Learned
- References
- Review Questions
This chapter is from the book
This chapter is from the book
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:
- Ensure that ACLs are enabled on the volume.
- 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.
- In the SAN Assets list, choose File Management.
- Select a SAN volume.
- Select the file or folder you want to protect and, from the Action (gear) pop-up menu, choose Set Permissions.
- Click the Add (+) button to add a user or group to the ACL (Access Control List) or POSIX permissions.
- 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.