diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.xml b/en_US.ISO8859-1/books/handbook/basics/chapter.xml
index bb43780cae..0b4bf61865 100644
--- a/en_US.ISO8859-1/books/handbook/basics/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/basics/chapter.xml
@@ -999,317 +999,6 @@ passwd: done
-
- Limiting Users
-
-
- limiting users
-
-
- accounts
- limiting
-
-
- &os; provides several methods for an administrator to
- limit the amount of system resources an individual may use.
- These limits are discussed in two sections: disk quotas and
- other resource limits.
-
-
- quotas
-
-
- limiting users
- quotas
-
-
- disk quotas
-
-
- Disk quotas limit the amount of disk space available to
- users and provide a way to quickly check that usage without
- calculating it every time. Quotas are discussed in
- .
-
- The other resource limits include ways to limit the amount
- of CPU, memory, and other resources a user may consume. These
- are defined using login classes and are discussed here.
-
-
- /etc/login.conf
-
-
- Login classes are defined in
- /etc/login.conf and are described in
- detail in &man.login.conf.5;. Each user account is assigned
- to a login class, default by default, and
- each login class has a set of login capabilities associated
- with it. A login capability is a
- name=value
- pair, where name is a well-known
- identifier and value is an
- arbitrary string which is processed accordingly depending on
- the name. Setting up login classes
- and capabilities is rather straightforward and is also
- described in &man.login.conf.5;.
-
-
- &os; does not normally read the configuration in
- /etc/login.conf directly, but instead
- reads the /etc/login.conf.db database
- which provides faster lookups. Whenever
- /etc/login.conf is edited, the
- /etc/login.conf.db must be updated by
- executing the following command:
-
- &prompt.root; cap_mkdb /etc/login.conf
-
-
- Resource limits differ from the default login capabilities
- in two ways. First, for every limit, there is a soft
- (current) and hard limit. A soft limit may be adjusted by the
- user or application, but may not be set higher than the hard
- limit. The hard limit may be lowered by the user, but can
- only be raised by the superuser. Second, most resource limits
- apply per process to a specific user, not to the user as a
- whole. These differences are mandated by the specific
- handling of the limits, not by the implementation of the login
- capability framework.
-
- Below are the most commonly used resource limits. The
- rest of the limits, along with all the other login
- capabilities, can be found in &man.login.conf.5;.
-
-
-
- coredumpsize
-
-
- The limit on the size of a core file
-
- coredumpsize
-
- generated by a program is subordinate to other limits
-
- limiting users
- coredumpsize
-
- on disk usage, such as filesize, or
- disk quotas. This limit is often used as a less-severe
- method of controlling disk space consumption. Since
- users do not generate core files themselves, and often
- do not delete them, setting this may save them from
- running out of disk space should a large program
- crash.
-
-
-
-
- cputime
-
-
- The maximum amount of CPU
-
- cputime
-
-
- limiting users
- cputime
-
- time a user's process may consume. Offending processes
- will be killed by the kernel.
-
-
- This is a limit on CPU time
- consumed, not percentage of the CPU as displayed in
- some fields by &man.top.1; and &man.ps.1;.
-
-
-
-
-
- filesize
-
-
- The maximum size of a file
-
- filesize
-
-
- limiting users
- filesize
-
- the user may own. Unlike
- disk quotas, this limit is
- enforced on individual files, not the set of all files a
- user owns.
-
-
-
-
- maxproc
-
-
- The maximum number of processes
-
- maxproc
-
-
- limiting users
- maxproc
-
- a user can run. This includes foreground and background
- processes. This limit may not be larger than the system
- limit specified by the kern.maxproc
- &man.sysctl.8;. Setting this limit too small may hinder
- a user's productivity as it is often useful to be logged
- in multiple times or to execute pipelines. Some tasks,
- such as compiling a large program, start lots of
- processes.
-
-
-
-
- memorylocked
-
-
- The maximum amount of memory
-
- memorylocked
-
-
- limiting users
- memorylocked
-
- a process may request to be locked into main memory
- using &man.mlock.2;. Some system-critical programs,
- such as &man.amd.8;, lock into main memory so that if
- the system begins to swap, they do not contribute to
- disk thrashing.
-
-
-
-
- memoryuse
-
-
- The maximum amount of memory
-
- memoryuse
-
-
- limiting users
- memoryuse
-
- a process may consume at any given time. It includes
- both core memory and swap usage. This is not a
- catch-all limit for restricting memory consumption, but
- is a good start.
-
-
-
-
- openfiles
-
-
- The maximum number of files a process may have open
-
- openfiles
-
-
- limiting users
- openfiles
- .
- In &os;, files are used to represent sockets and IPC
- channels, so be careful not to set this too low. The
- system-wide limit for this is defined by the
- kern.maxfiles &man.sysctl.8;.
-
-
-
-
- sbsize
-
-
- The limit on the amount of network memory, and
- thus mbufs
-
- sbsize
-
-
- limiting users
- sbsize
- ,
- a user may consume. This can be generally used to limit
- network communications.
-
-
-
-
- stacksize
-
-
- The maximum size of a process stack
-
- stacksize
-
-
- limiting users
- stacksize
- .
- This alone is not sufficient to limit the amount of
- memory a program may use so it should be used in
- conjunction with other limits.
-
-
-
-
- There are a few other things to remember when setting
- resource limits. Following are some general tips,
- suggestions, and miscellaneous comments.
-
-
-
- Processes started at system startup by
- /etc/rc are assigned to the
- daemon login class.
-
-
-
- Although the /etc/login.conf that
- comes with the system is a good source of reasonable
- values for most limits, they may not be appropriate for
- every system. Setting a limit too high may open the
- system up to abuse, while setting it too low may put a
- strain on productivity.
-
-
-
- Users of &xorg; should
- probably be granted more resources than other users.
- &xorg; by itself takes a lot of
- resources, but it also encourages users to run more
- programs simultaneously.
-
-
-
- Many limits apply to individual processes, not the
- user as a whole. For example, setting
- openfiles to 50 means that each process
- the user runs may open up to 50 files. The total amount
- of files a user may open is the value of
- openfiles multiplied by the value of
- maxproc. This also applies to memory
- consumption.
-
-
-
- For further information on resource limits and login
- classes and capabilities in general, refer to
- &man.cap.mkdb.1;, &man.getrlimit.2;, and
- &man.login.conf.5;.
-
-
Managing Groups
diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.xml b/en_US.ISO8859-1/books/handbook/security/chapter.xml
index b3f6e2a99d..809dbcd3c5 100644
--- a/en_US.ISO8859-1/books/handbook/security/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/security/chapter.xml
@@ -90,8 +90,8 @@
- Understand the resource limits database and how to
- utilize it to control user resources.
+ How to control user resources using login classes or the
+ resource limits database.
@@ -3539,6 +3539,320 @@ UWWemqWuz3lAZuORQ9KX
and to set rules on system initialization using a configuration
file.
+ This section demonstrates both methods for controlling
+ resources.
+
+
+ Login Classes
+
+
+ limiting users
+
+
+ accounts
+ limiting
+
+
+ &os; provides several methods for an administrator to
+ limit the amount of system resources an individual may use.
+ These limits are discussed in two sections: disk quotas and
+ other resource limits.
+
+
+ quotas
+
+
+ limiting users
+ quotas
+
+
+ disk quotas
+
+
+ Disk quotas limit the amount of disk space available to
+ users and provide a way to quickly check that usage without
+ calculating it every time. Quotas are discussed in
+ .
+
+ The other resource limits include ways to limit the amount
+ of CPU, memory, and other resources a user may consume. These
+ are defined using login classes and are discussed here.
+
+
+ /etc/login.conf
+
+
+ Login classes are defined in
+ /etc/login.conf and are described in
+ detail in &man.login.conf.5;. Each user account is assigned
+ to a login class, default by default, and
+ each login class has a set of login capabilities associated
+ with it. A login capability is a
+ name=value
+ pair, where name is a well-known
+ identifier and value is an
+ arbitrary string which is processed accordingly depending on
+ the name. Setting up login classes
+ and capabilities is rather straightforward and is also
+ described in &man.login.conf.5;.
+
+
+ &os; does not normally read the configuration in
+ /etc/login.conf directly, but instead
+ reads the /etc/login.conf.db database
+ which provides faster lookups. Whenever
+ /etc/login.conf is edited, the
+ /etc/login.conf.db must be updated by
+ executing the following command:
+
+ &prompt.root; cap_mkdb /etc/login.conf
+
+
+ Resource limits differ from the default login capabilities
+ in two ways. First, for every limit, there is a soft
+ (current) and hard limit. A soft limit may be adjusted by the
+ user or application, but may not be set higher than the hard
+ limit. The hard limit may be lowered by the user, but can
+ only be raised by the superuser. Second, most resource limits
+ apply per process to a specific user, not to the user as a
+ whole. These differences are mandated by the specific
+ handling of the limits, not by the implementation of the login
+ capability framework.
+
+ Below are the most commonly used resource limits. The
+ rest of the limits, along with all the other login
+ capabilities, can be found in &man.login.conf.5;.
+
+
+
+ coredumpsize
+
+
+ The limit on the size of a core file
+
+ coredumpsize
+
+ generated by a program is subordinate to other limits
+
+ limiting users
+ coredumpsize
+
+ on disk usage, such as filesize, or
+ disk quotas. This limit is often used as a less-severe
+ method of controlling disk space consumption. Since
+ users do not generate core files themselves, and often
+ do not delete them, setting this may save them from
+ running out of disk space should a large program
+ crash.
+
+
+
+
+ cputime
+
+
+ The maximum amount of CPU
+
+ cputime
+
+
+ limiting users
+ cputime
+
+ time a user's process may consume. Offending processes
+ will be killed by the kernel.
+
+
+ This is a limit on CPU time
+ consumed, not percentage of the CPU as displayed in
+ some fields by &man.top.1; and &man.ps.1;.
+
+
+
+
+
+ filesize
+
+
+ The maximum size of a file
+
+ filesize
+
+
+ limiting users
+ filesize
+
+ the user may own. Unlike
+ disk quotas, this limit is
+ enforced on individual files, not the set of all files a
+ user owns.
+
+
+
+
+ maxproc
+
+
+ The maximum number of processes
+
+ maxproc
+
+
+ limiting users
+ maxproc
+
+ a user can run. This includes foreground and background
+ processes. This limit may not be larger than the system
+ limit specified by the kern.maxproc
+ &man.sysctl.8;. Setting this limit too small may hinder
+ a user's productivity as it is often useful to be logged
+ in multiple times or to execute pipelines. Some tasks,
+ such as compiling a large program, start lots of
+ processes.
+
+
+
+
+ memorylocked
+
+
+ The maximum amount of memory
+
+ memorylocked
+
+
+ limiting users
+ memorylocked
+
+ a process may request to be locked into main memory
+ using &man.mlock.2;. Some system-critical programs,
+ such as &man.amd.8;, lock into main memory so that if
+ the system begins to swap, they do not contribute to
+ disk thrashing.
+
+
+
+
+ memoryuse
+
+
+ The maximum amount of memory
+
+ memoryuse
+
+
+ limiting users
+ memoryuse
+
+ a process may consume at any given time. It includes
+ both core memory and swap usage. This is not a
+ catch-all limit for restricting memory consumption, but
+ is a good start.
+
+
+
+
+ openfiles
+
+
+ The maximum number of files a process may have open
+
+ openfiles
+
+
+ limiting users
+ openfiles
+ .
+ In &os;, files are used to represent sockets and IPC
+ channels, so be careful not to set this too low. The
+ system-wide limit for this is defined by the
+ kern.maxfiles &man.sysctl.8;.
+
+
+
+
+ sbsize
+
+
+ The limit on the amount of network memory, and
+ thus mbufs
+
+ sbsize
+
+
+ limiting users
+ sbsize
+ ,
+ a user may consume. This can be generally used to limit
+ network communications.
+
+
+
+
+ stacksize
+
+
+ The maximum size of a process stack
+
+ stacksize
+
+
+ limiting users
+ stacksize
+ .
+ This alone is not sufficient to limit the amount of
+ memory a program may use so it should be used in
+ conjunction with other limits.
+
+
+
+
+ There are a few other things to remember when setting
+ resource limits. Following are some general tips,
+ suggestions, and miscellaneous comments.
+
+
+
+ Processes started at system startup by
+ /etc/rc are assigned to the
+ daemon login class.
+
+
+
+ Although the /etc/login.conf that
+ comes with the system is a good source of reasonable
+ values for most limits, they may not be appropriate for
+ every system. Setting a limit too high may open the
+ system up to abuse, while setting it too low may put a
+ strain on productivity.
+
+
+
+ Users of &xorg; should
+ probably be granted more resources than other users.
+ &xorg; by itself takes a lot of
+ resources, but it also encourages users to run more
+ programs simultaneously.
+
+
+
+ Many limits apply to individual processes, not the
+ user as a whole. For example, setting
+ openfiles to 50 means that each process
+ the user runs may open up to 50 files. The total amount
+ of files a user may open is the value of
+ openfiles multiplied by the value of
+ maxproc. This also applies to memory
+ consumption.
+
+
+
+ For further information on resource limits and login
+ classes and capabilities in general, refer to
+ &man.cap.mkdb.1;, &man.getrlimit.2;, and
+ &man.login.conf.5;.
+
+
Enabling and Configuring Resource Limits