Managing User Resources
Creating user accounts is only part of a system administrator's job. Management of user resources is also essential. Therefore, three points must be considered:
Who can access shared data.
Where users access this data.
What barriers are in place to prevent abuse of resources.
This section will briefly review each of these topics.
Who Can Access Shared Data
The identity of those who can access a given application, file, or directory on a system is determined by its permissions. By default, Red Hat Linux places reasonable permissions on the file system.
For instance, the /tmp directory, which is world-writable, also has the sticky bit set. This means that only the user who writes a file to the directory can delete it. This prevents other users from mistakenly or maliciously deleting the files of others.
Another example are the permissions assigned by default to a user's home directory. Only the owner of the home directory can create or view files there. Other users on the system are denied all access. This increases user privacy and prevents possible misappropriation of personal files.
But there are many situations where multiple users may need access to the same resources on a machine. In this case, careful creation of shared groups may be necessary.
Groups and Shared Data
As mentioned in the introduction, groups are logical constructs that can be used to cluster user accounts together for a specific purpose. When managing users within an organization, it is wise to identify what data should be accessed by certain departments, what data should be denied to others, and what data should be shared by all. Determining this will aid in creating an appropriate group structure, along with permissions appropriate for the shared data.
For instance, let us say that the Accounts Receivable department needs to maintain a list of accounts that are delinquent on their payments. They must also share that list with the Collections department. If both Accounts Receivable and Collections personnel are placed in a group called accounts, this information can then be placed in a shared directory (owned by group accounts) with group read and write permissions on the directory.
Determining Group Structure
Some of the challenges facing system administrators when creating shared groups are:
What groups to create?
Who to put in a given group?
What type of permissions should these shared resources have?
A common sense approach to these questions is helpful. For instance, it is often best to mirror the organizational structure when creating groups. For instance, if there is a Finance department, then create a group called finance, and make all Finance personnel member of that group. If the financial information is too sensitive for the company at large, but vital for senior officials within the organization, then grant the senior officials group permission to access the directories and data used by the finance department by adding all senior officials to the finance group.
It is also good to err on the side of caution when granting permissions to users. This way, sensitive information is less likely to fall into the wrong hands.
By approaching the group structure for an organization in this way, the need for access to share data within the organization can be safely and effectively met.
Where Users Access Shared Data
When sharing data among users, it is common practice to have a central server (or group of servers) that export certain directories to other machines on the network. This way data is stored in one place; synchronizing data between multiple machines is not necessary.
One of the best ways to share directories under Red Hat Linux is to use NFS. For more information on mounting and exporting directories using NFS, see the chapter titled Network File System (NFS) in the Official Red Hat Linux Customization Guide.
If your network includes other platforms, you may also find it necessary to share directories using Samba. See the chapter titled Samba in the Official Red Hat Linux Customization Guide for more information.
Unfortunately, once data is shared between multiple computers on a network, the potential for conflicts in file ownership can arise.
The UID/GID Conundrum
As mentioned in the Section called Usernames and UIDs, Groups and GIDs, user account and group names are primarily for peoples' convenience. All other applications and processes on the system only operate on UIDs and GIDs. This fact is normally transparent to users, until a user accesses a shared volume. If the /etc/passwd and /etc/group files on the file server and the user's machine differ in the UIDs or GIDs they contain, improper application of permissions can lead to security issues.
For example, if user juan has a UID of 500 on a desktop computer, files juan creates on a file server will be created with owner UID 500. However, if user bob logs in locally to the file server, and bob's account also has a UID of 500, bob will have full access to juan's files, and vice versa.
One of the best ways to avoid this issue is to centrally manage the /etc/passwd and /etc/group files using Network Information Services (NIS), Lightweight Directory Access Protocol (LDAP), or Hesiod. This way all users on the network share the same user database and ownership conflicts on shared volumes are eliminated.
 | Caution |
|---|---|
Although it is a good idea to centralize the information contained in /etc/passwd using these mechanisms, for security reasons it is not a good idea to use them to centralize the information contained in the /etc/shadow or the /etc/gshadow files. Instead, consider using Kerberos for this purpose. See the chapter titled Kerberos in the Official Red Hat Linux Customization Guide for more information on how to accomplish this. |
Home Directories
Another issue facing administrators is whether or not users should have centralized home directories.
By default, Red Hat Linux creates home directories for new users in the /home/ directory. This is fine for stand alone machines, but within an organization, it may be helpful to users to have home directories centralized.
The primary advantage of centralizing home directories on a network-attached server is that if a user logs into any machine on the network, they will be able to access the files in their home directory. The disadvantage is that if the network goes down, users across the entire organization will be unable to get to their files.
In some situations (such as laptops), having centralized home directories may not be practical. But if the administrator deems it appropriate, either NIS or LDAP (in conjunction with NFS) is an effective means of implementing centralized home directories.
What Barriers Are in Place To Prevent Abuse of Resources
Careful organization of groups and assignment of permissions for shared resources is one of the most important things an administrator can do to prevent abuse among users within an organization. This way those who should not have access to sensitive resources are denied access.
But the best guard against abuse of resources is always sustained vigilance on the part of the systems administrator.