Resource management is one of the administrator's key responsibilities, particularly where the availability of a service is the organization's primary source of income (or recognition). For example, if an application server requires 10MB of free disk space for internal caching of objects retrieved from a database, performance on the client side will suffer if this space is not available because a user decided to dump his or her collection of MP3 music files onto the system hard drive. If external users cannot access a service because of internal resource allocation problems, they are unlikely to continue using your service. There is also a possibility that a rogue user (or competitor) may attempt to disrupt your service by attempting any number of well-known exploits to reduce your providing service to clients. In this section, we examine resource management strategies that are flexible enough to meet the needs of casual users, but which limit the potential for accidental or malicious resource misuse.
Solaris provides a number of tools to enforce policies on disk and resource usage, based around the idea of quotas, or a prespecified allocation of disk space for each user and file system. Thus, a single user can have disk space allocated on different slices, and file systems can have quotas either enabled or disabled (they are disabled by default). Although many organizations disable disk quotas for fear of reducing productivity by placing unnecessary restrictions on the development staff, there are often some very good reasons for implementing quotas on specific slices. For example, if an open file area, like an anonymous FTP 'incoming' directory, is located on the same partition as normal user data, a denial-of-service attack could be initiated by a rogue user who decides to fill the incoming directory with large files until all free space is consumed. Or, a CGI application that writes data to a user's home directory (for example, a guestbook) can also fall victim to a denial-of-service attack: a malicious script could be written to enter a million fake entries into the address book, thereby filling the partition to capacity. The result in both of these cases is loss of service and loss of system control. It is therefore important that networked systems have appropriate checks and balances in place to ensure that such situations are avoided.
Quotas are also critical to ensure fair resource sharing among developers. Otherwise, a developer who decides to back up his PC drive to his home directory on a server, completely filling the partition, could prevent other users from writing valuable data.
In addition to security concerns, enforcing quotas is also optimal from an administrative point of view-it forces users to rationalize their own storage requirements, so that material that is not being used can be moved offline or deleted. This saves administrators from having to make such decisions for users (who may be dismayed at the results if the administrator has to move things in a hurry!).
One simple policy is to enforce disk quotas on all public file systems that have network access. Increasing quotas for all users is easy, so the policy can be flexible. In addition, quotas can be hard or soft: hard quotas strictly enforce incursions into unallocated territory, whereas soft quotas provide a buffer for temporary violations of a quota, and the users are given warning before enforcement begins.
Depending on the security level at which your organization operates (for example, C2 standards for military organizations), a quota policy may already be available for you to implement.
A total limit on the amount of disk space available to users can be specified using quotas for each user individually. Let's take the user pwatters on server as an example. You may allot this user, a Java developer, a quota of 10MB for development work on the /staff file system. To set up this quota, you need to undertake the following steps:
Edit the /etc/vfstab file as root and add the rq flag to the mount options field for the /staff file system. This enables quotas for the file system.
Change directory to /staff and create a file called quotas.
Set permissions on /staff/quotas to be read and write for root only.
Edit user quotas for user pwatters on file system /staff by using the edquota command and entering the number of inodes and 1KB blocks that will be available to user pwatters-for example, enter the following:
fs /staff blocks (soft = 10000, hard = 11000) inodes (soft = 0, hard = 0)
Check the settings that you have created by using the quota command.
Enable the quota for user pwatters by using the quotaon command.
You can implement these steps by entering the following:
# vi /etc/vfstab # cd /staff # touch quotas # chmod u+rw quotas # edquota pwatters # quota -v pwatters # quotaon /staff
When you verify the quotas using quota -v,
# quota -v pwatters
the output should look like the following:
Disk quotas for pwatters (uid 1001): Filesystem usage quota limit timeleft files quota /staff 0 10000 11000 0 0 0
You can see that a soft limit of 10MB and a hard limit of 11MB was entered for user pwatters. If halfway through the development project this user requests more space, you could adjust the quota by using the edquota command again. To check quotas for all users, use the repquota command:
# repquota /staff Block limits User used soft hard jsmith -- 2048 4096 8192 pwatters -- 131 10000 20000 qjones -- 65536 90000 100000 llee -- 4096 8192 10000
If a user attempts to exceed his or her quota during an interactive session, unless you've set up a warning to be issued under those circumstances, the first indication that the user will have will often come in the form of a 'file system full' or 'write failed' message. After checking the amount of free space on the partition where their home disk is located, many users are at a loss to explain why they can no longer edit files or send e-mail!