Resource Limiting: Difference between revisions

From Extremely Corporate Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
[[Category:Software]]
One of the ways of securing a server is to impose resource limits on users. This can prevent people from making the server unusable either by accident or on purpose.
One of the ways of securing a server is to impose resource limits on users. This can prevent people from making the server unusable either by accident or on purpose.



Revision as of 05:06, 9 April 2022


One of the ways of securing a server is to impose resource limits on users. This can prevent people from making the server unusable either by accident or on purpose.

The 3 most important "resources" are:

  1. The amount of the CPU's time dedicated to a single user's processes
  2. The amount of memory a single user can take up
  3. The amount of storage a single user can fill up

There are other things to pay attention to, such as controlling how many/whether or not ports can be bound by the user's processes. It is also the case that you may want to apply strict limits to user accounts controlled by actual people, but not to accounts used by the system for running services. For this purpose, the examples on this page will make reference to a group called users the members of which are all user accounts.

limits.conf

You can configure resource limits with /etc/security/limits.conf and every file in the /etc/security/limits.d/ directory. In these files, you define limits which apply to either specific users or groups of users. Applying limits in these files is effective for restricting CPU usage and memory usage, but not storage usage. Here are some example configurations:

  • Rules qualified by * apply to every user
  • Rules qualified by just a name apply to the user with that name
  • Rules qualified by a name prefixed by @ apply to the members of the group with that name
# /etc/security/limits.conf

# This configuration makes sure no core files are produced
# and also reserves the highest process priority for the
# root user so that an unresponsive system can be more easily
# recovered.

*               hard    core            0
*               hard    nice            -19
root            hard    nice            -20
# /etc/security/limits.d/users.conf

# This configuration limits the priority of those processes to
# 10 ensuring the system never prioritizes a user's process
# over those belonging to services (default priority is 0).
# This configuration also limits each user's memory usage to
# at most 1 gigabyte.
 
# Nice limit (negative = higher priority, positive = lower priority)
@users          hard    nice            10
# Default priority
@users          hard    priority        10

# Memory limit (in kilobytes)
@users          hard    as              1000000

NOTE: For systems using PAM (most systems today), you might have to explicitly configure the reloading of your limits configuration when changing users with su. To do so, add the following line to /etc/pam.d/su:

session         required        pam_limits.so set_all

The set_all option is significant. Without it, only limits with explicit values for the current user will be set (default limits will be ignored). Some distributions of PAM have this on by default, but it's better to be safe than sorry.

Quotas

Disk quotas allow you to put limits on the amount of storage space users can take up. They can be applied per-user or per-group. Be aware that a group limit does not apply to the files owned by users who are members of a given group. Group quotas apply strictly to files owned by that group. To make use of them, enable quotas on the partitions where users can write files. You can do this by adding the following mount options to the entry in /etc/fstab:

If your kernel supports journaled quotas (it probably does):

  • usrjquota=aquota.user (for user quotas)
  • grpjquota=aquota.group (for group quotas)
  • jqfmt=vfsv1

If your kernel does not support journaled quotas:

  • usrquota (for user quotas)
  • grpquota (for group quotas)

After modifying the mount options, remount each partition to which you added quotas and make sure there are no errors before proceeding.

Before you can enable quotas, you must create the files in which the quotas will be stored. You can do this by running quotacheck -cugma.

You should now be able to enable quotas with quotaon -a.

With quotas enabled, you can start editing the quotas for groups and users with edquota either as edquota user or edquota -g group. The blocks and inodes columns indicate current usage and are not editable. To define their limits, edit their respective hard and soft columns. Each "block" is 1k bytes.

You can inspect quotas using repquota -a.

Unlike limits.conf, there isn't a simple or nice way to define quotas that apply individually to every member of a given group. Instead, you can define a user quota on one member of a group, then copy it to every other member of that group. Here is a script which does just that:

#!/bin/bash

PROTOTYPE_USER=p_user
IFS=',' && for user in `getent group group | cut -d : -f 4`; do
    edquota -p "$PROTOTYPE_USER" "$user"
done

Replace p_user with the name for which you defined the quota you want to duplicate.

Replace group with the name of the group to which the users to whom you want the quota duplicated belong.