- 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
Controlling User Access
In the previous exercises, you explored SAN-level and volume-level control. In this section, you will examine file- and folder-level control.
To increase security and reliability, Mac OS X sets ownership of many system folders, such as a newly created Xsan volume, to the root user (literally, a user named root). Newly created Xsan volumes are, by default, also owned by root. Files and folders owned by root can’t be changed or deleted unless you’re logged in as root. But be careful. Few access restrictions are placed on the root user, and you could change system data that may cause problems.
Files and folders are, by default, owned by the users who create them. After files and folders are created, those items keep their privileges (a combination of ownership and permissions) even when they are moved, unless the privileges are explicitly changed by their owners or by an administrator. New files and folders that you create as an administrator are not accessible by client users if they are created in folders for which the users don’t have privileges.
When setting up Xsan volumes, make sure that the files and folders allow the appropriate access privileges for the users who need access to them. A useful method to ensure this is by using groups and group memberships.
In Mac OS X Client, every user is a member of a default group that is created at the same time as the user account and has the same name as the user name for that user account. This user is the only member of this group. For example, if you created a user, ravi, on a local machine, the operating system would create a group, also called ravi, in which to place that user. This situation can restrict access to files and folders on a shared Xsan volume because that group does not exist on the servers managing the Xsan.
For Xsan volumes, by default, group ownership is assigned to a group called wheel, a system group made up of administrative users. It is common practice to change this default group ownership on an Xsan volume. Common replacements groups are called Editors or Xsan Users, and are managed centrally from a directory system, such as Open Directory, using Server Admin.
Managing Local Users
Xsan tracks file ownership based on user IDs and group IDs. In this respect, Xsan is similar to UFS, NFS, and Mac OS X Extended format. Each file and folder is marked with a numeric user ID and a numeric group ID. Ownership and group access are evaluated by comparing the UID of the file system object with the UID of the user. Permissions are applied depending on whether the user is identified as the owner, the group member, or neither.
)
If two different users on different clients have the same user ID, files will be associated with the same user ID, and both users will have the same access. This can happen naturally when you follow the default Mac OS X installation process. The first user created by the Setup Assistant is user ID 501. All computers connected to the SAN volume will have user ID 501 if they retain the ID created during Mac OS X configuration.
This situation may work well for small sites. For example, if your Xsan clients are video production workstations, it may fit your workflow to have all users share access to the volume files. However, due to the possibility of UNIX ID duplication, users may gain access to files for which they do not specifically have permission or for which you did not intend to provide access. This situation also makes it almost impossible to meet any regulatory compliance standards through audits and the like, because you cannot adequately determine which user was using a specific machine at a given time and what he was doing on that machine.
Understanding umask
In Mac OS X and other POSIX-based systems, a value known as a umask is subtracted from the system’s maximum permissions value (typically 777) to determine the default permission value of a newly created file. The umask can play a role in a group’s working environment, such as sharing files in a group folder on a server.
)
Mac OS X applies default permissions to newly created files and folders. The owner has full read/write access to local files, and everyone else has read-only access. Each operating system assigns a default permission value (such as 755 in Mac OS X v10.5) to files and folders. Default permissions exist to ensure a balance between security and access, and to see that the appropriate users have correct levels of access to a file in most situations.
Looking at the figure above, notice that there are three columns: read, write, and execute. Each row in the chart identifies a different level of permission associated with the ability to read, write, or execute specific files. A person with a umask of 000 would have a permissions value of 777 (777-000 = 777). This person would be able to read, write, and execute within the group directory. A person with a umask of 022 would be able to read and execute, but not write.
To understand how this functions, note that a umask of 022 typically results in the default permission of 755. So, assume that a Mac OS X v10.5 client with a umask value of 022 opens a file from the group folder and saves it, resulting in a permission value of 755. This happens because the Mac OS X client’s umask of 022 wrote the file back to the group folder without group write permission (775 includes group write; 755 does not). Because inherited permissions were disabled on the server, the server did nothing to control the situation.
The default umask setting can be changed using the default write commands for both the Finder and the BSD subsystem to enable group read/write access by default for newly created files and folders. In the absence of a centralized directory, such as Apple’s Open Directory, this can be a useful setting for enabling collaborative workflows on shared Xsan volumes.
For more information, consult Knowledge Base article #HT2202, “Mac OS X Server 10.5: Setting a custom umask” (http://support.apple.com/kb/HT2202).
Managing Network Users
For a larger site, or if you’re using Xsan as a repository for server data, your security requirements might not be best served if you give all users the same access to an Xsan volume. In these cases, the solution is a directory service. With a directory server on the network, each user can have a unique ID that is visible to all SAN clients. Identify all of your SAN clients as clients of the directory server, and those clients will use a unified user list in which you can eliminate duplicate user IDs.
)
Xsan supports any directory service supported by the Open Directory client in Mac OS X. Open Directory Server in Mac OS X Server is easy to configure, but if your site already has an LDAP directory or a Microsoft Active Directory, you can also integrate with those.
If you do decide to integrate Mac OS X v10.5 clients into an Active Directory, make sure that all computers on the SAN use the same Active Directory domain and the same method of ID mapping.
Mapping Windows User and Group IDs
You can use the Windows ID Mapping setting for a volume to specify how Windows clients map user and group information to Xsan-compatible user IDs (UIDs) and group IDs (GIDs) that they need in order to access Xsan volumes.
Windows clients can use one of the following methods to provide UIDs and GIDs:
-
Generate IDs from GUID—Windows clients dynamically generate UIDs and GIDs based on Globally Unique Identifier (GUID) information in an Active Directory domain. Choose this method for Macintosh computers on the SAN that are bound (connected) to Active Directory with the binding options set to automatically generate IDs.
-
Use IDs from LDAP (RFC 2307)—Windows clients get UID and GID values from the uidNumber and gidNumber attributes in Active Directory records. Choose this method for Macintosh computers on the SAN that are bound to Active Directory with the binding options set to map IDs to uidNumber and gidNumber.
The Active Directory binding options are set using Directory Utility in Mac OS X v10.5 or using Directory Access in Mac OS X v10.4. You can find these applications in /Applications/Utilities.
To select the Windows IP mapping method, follow these steps:
- In Xsan Admin, in the SAN Assets list, choose Volumes, and from the Action (gear) pop-up menu, choose Edit Volume Settings.
- From the Windows ID Mapping pop-up menu, choose a mapping method.
If you choose “Use IDs from LDAP (RFC 2307),” you can change the ID numbers used when a directory record doesn’t include a uidNumber or gidNumber attribute.
- Click OK.
Xsan Admin automatically unmounts the volume from all clients and controllers and stops the volume before changing the Windows ID mapping method, and then starts the volume and mounts it on each computer on which it was mounted.
If you modified the Windows IP mapping while the volume was in use, your users will be disconnected from the SAN, and users in a video production environment will experience dropped frames. It is important to let your users know in advance if you plan to make such a change.