| Red Hat Linux 9: Red Hat Linux System Administration Primer | ||
|---|---|---|
| Prev | Chapter 6. Managing User Accounts and Resource Access | Next |
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
The following sections briefly review each of these topics.
A user's access to a given application, file, or directory is determined by the permissions applied to that application, file, or directory.
In addition, it is often helpful if different permissions can be applied to different classes of users. For example, shared temporary storage should be capable of preventing the accidental (or malicious) deletions of a user's files by all other users, while still permitting the file's owner full access.
Another example is the access assigned to a user's home directory. Only the owner of the home directory should be able to create or view files there. Other users should be denied all access (unless the user wishes otherwise). 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.
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 the creation of an appropriate group structure, along with permissions appropriate for the shared data.
For instance, assume that that the accounts receivable department must 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 made members of a group called accounts, this information can then be placed in a shared directory (owned by the accounts group) with group read and write permissions on the directory.
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. One possibility is to mirror your organization's structure when creating groups. For example, if there is a finance department, create a group called finance, and make all finance personnel members 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-level 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 creation of your organization's group structure in this manner, the need for access to shared data within the organization can be safely and effectively met.
When sharing data among users, it is a common practice to have a central server (or group of servers) that make certain directories available to other machines on the network. This way data is stored in one place; synchronizing data between multiple machines is not necessary.
Before taking this approach, you must first determine what systems are to access the centrally-stored data. As you do this, take note of the operating systems used by the systems. This information will have a bearing on your ability to implement such an approach, as your storage server must be capable of serving its data to each of the operating systems in use at your organization.
Unfortunately, once data is shared between multiple computers on a network, the potential for conflicts in file ownership can arise.
There are benefits if data is stored centrally and is accessed by multiple computers over a network. However, assume for a moment that each of those computers has a locally-maintained list of user accounts. What if the list of users on each of these systems are not consistent with the list of users on the central server? Even worse, what if the list of users on each of these systems are not even consistent with each other?
Much of this depends on how users and access permissions are implemented on each system, but in some cases it is possible that user A on one system may actually be known as user B on another system. This becomes a real problem when data is shared between these systems, as data that user A is allowed to access from one system can also be read by user B from another system.
For this reason, many organizations use some sort of central user database. This assures that there are no overlaps between user lists on different systems.
Another issue facing system administrators is whether or not users should have centrally-stored home directories.
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 organizations that make widespread use of laptops), having centralized home directories may not be desirable. But if it makes sense for your organization, deploying centralized home directories can make a system administrator's life much easier.
The careful organization of groups and assignment of permissions for shared resources is one of the most important things a system administrator can do to prevent resource abuse among users within an organization. In this way, those who should not have access to sensitive resources are denied access.
But no matter how your organization does things, the best guard against abuse of resources is always sustained vigilance on the part of the system administrator. Keeping your eyes open is often the only way to avoid having an unpleasant surprise waiting for you at your desk one morning.