Resource Limiting: Difference between revisions
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:
- The amount of the CPU's time dedicated to a single user's processes
- The amount of memory a single user can take up
- 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.