svn commit: r44718 - in head/en_US.ISO8859-1/books/handbook: basics security
Dru Lavigne
dru at FreeBSD.org
Wed Apr 30 14:45:09 UTC 2014
Author: dru
Date: Wed Apr 30 14:45:09 2014
New Revision: 44718
URL: http://svnweb.freebsd.org/changeset/doc/44718
Log:
Move 4.3.3 Limiting Users to a subsection of 14.13 Resource Limits.
The next commit will do a tech/editorial review of the moved subsection.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Wed Apr 30 10:53:40 2014 (r44717)
+++ head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Wed Apr 30 14:45:09 2014 (r44718)
@@ -999,317 +999,6 @@ passwd: done</screen>
</sect3>
</sect2>
- <sect2 xml:id="users-limiting">
- <title>Limiting Users</title>
-
- <indexterm>
- <primary>limiting users</primary>
- </indexterm>
- <indexterm>
- <primary>accounts</primary>
- <secondary>limiting</secondary>
- </indexterm>
-
- <para>&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.</para>
-
- <indexterm>
- <primary>quotas</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>quotas</secondary>
- </indexterm>
- <indexterm>
- <primary>disk quotas</primary>
- </indexterm>
-
- <para>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
- <xref linkend="quotas"/>.</para>
-
- <para>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.</para>
-
- <indexterm>
- <primary><filename>/etc/login.conf</filename></primary>
- </indexterm>
-
- <para>Login classes are defined in
- <filename>/etc/login.conf</filename> and are described in
- detail in &man.login.conf.5;. Each user account is assigned
- to a login class, <literal>default</literal> by default, and
- each login class has a set of login capabilities associated
- with it. A login capability is a
- <literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>
- pair, where <replaceable>name</replaceable> is a well-known
- identifier and <replaceable>value</replaceable> is an
- arbitrary string which is processed accordingly depending on
- the <replaceable>name</replaceable>. Setting up login classes
- and capabilities is rather straightforward and is also
- described in &man.login.conf.5;.</para>
-
- <note>
- <para>&os; does not normally read the configuration in
- <filename>/etc/login.conf</filename> directly, but instead
- reads the <filename>/etc/login.conf.db</filename> database
- which provides faster lookups. Whenever
- <filename>/etc/login.conf</filename> is edited, the
- <filename>/etc/login.conf.db</filename> must be updated by
- executing the following command:</para>
-
- <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
- </note>
-
- <para>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.</para>
-
- <para>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;.</para>
-
- <variablelist>
- <varlistentry>
- <term><literal>coredumpsize</literal></term>
-
- <listitem>
- <para>The limit on the size of a core file
- <indexterm>
- <primary>coredumpsize</primary>
- </indexterm>
- generated by a program is subordinate to other limits
- <indexterm>
- <primary>limiting users</primary>
- <secondary>coredumpsize</secondary>
- </indexterm>
- on disk usage, such as <literal>filesize</literal>, 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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>cputime</literal></term>
-
- <listitem>
- <para>The maximum amount of CPU
- <indexterm>
- <primary>cputime</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>cputime</secondary>
- </indexterm>
- time a user's process may consume. Offending processes
- will be killed by the kernel.</para>
-
- <note>
- <para>This is a limit on CPU <emphasis>time</emphasis>
- consumed, not percentage of the CPU as displayed in
- some fields by &man.top.1; and &man.ps.1;.</para>
- </note>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>filesize</literal></term>
-
- <listitem>
- <para>The maximum size of a file
- <indexterm>
- <primary>filesize</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>filesize</secondary>
- </indexterm>
- the user may own. Unlike
- <link linkend="quotas">disk quotas</link>, this limit is
- enforced on individual files, not the set of all files a
- user owns.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>maxproc</literal></term>
-
- <listitem>
- <para>The maximum number of processes
- <indexterm>
- <primary>maxproc</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>maxproc</secondary>
- </indexterm>
- a user can run. This includes foreground and background
- processes. This limit may not be larger than the system
- limit specified by the <varname>kern.maxproc</varname>
- &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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>memorylocked</literal></term>
-
- <listitem>
- <para>The maximum amount of memory
- <indexterm>
- <primary>memorylocked</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>memorylocked</secondary>
- </indexterm>
- 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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>memoryuse</literal></term>
-
- <listitem>
- <para>The maximum amount of memory
- <indexterm>
- <primary>memoryuse</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>memoryuse</secondary>
- </indexterm>
- 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.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>openfiles</literal></term>
-
- <listitem>
- <para>The maximum number of files a process may have open
- <indexterm>
- <primary>openfiles</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>openfiles</secondary>
- </indexterm>.
- 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
- <varname>kern.maxfiles</varname> &man.sysctl.8;.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>sbsize</literal></term>
-
- <listitem>
- <para>The limit on the amount of network memory, and
- thus mbufs
- <indexterm>
- <primary>sbsize</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>sbsize</secondary>
- </indexterm>,
- a user may consume. This can be generally used to limit
- network communications.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><literal>stacksize</literal></term>
-
- <listitem>
- <para>The maximum size of a process stack
- <indexterm>
- <primary>stacksize</primary>
- </indexterm>
- <indexterm>
- <primary>limiting users</primary>
- <secondary>stacksize</secondary>
- </indexterm>.
- 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.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>There are a few other things to remember when setting
- resource limits. Following are some general tips,
- suggestions, and miscellaneous comments.</para>
-
- <itemizedlist>
- <listitem>
- <para>Processes started at system startup by
- <filename>/etc/rc</filename> are assigned to the
- <literal>daemon</literal> login class.</para>
- </listitem>
-
- <listitem>
- <para>Although the <filename>/etc/login.conf</filename> 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.</para>
- </listitem>
-
- <listitem>
- <para>Users of <application>&xorg;</application> should
- probably be granted more resources than other users.
- <application>&xorg;</application> by itself takes a lot of
- resources, but it also encourages users to run more
- programs simultaneously.</para>
- </listitem>
-
- <listitem>
- <para>Many limits apply to individual processes, not the
- user as a whole. For example, setting
- <varname>openfiles</varname> 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
- <literal>openfiles</literal> multiplied by the value of
- <literal>maxproc</literal>. This also applies to memory
- consumption.</para>
- </listitem>
- </itemizedlist>
-
- <para>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;.</para>
- </sect2>
-
<sect2 xml:id="users-groups">
<title>Managing Groups</title>
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 10:53:40 2014 (r44717)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 14:45:09 2014 (r44718)
@@ -90,8 +90,8 @@
</listitem>
<listitem>
- <para>Understand the resource limits database and how to
- utilize it to control user resources.</para>
+ <para>How to control user resources using login classes or the
+ resource limits database.</para>
</listitem>
</itemizedlist>
@@ -3539,6 +3539,320 @@ UWWemqWuz3lAZuORQ9KX
and to set rules on system initialization using a configuration
file.</para>
+ <para>This section demonstrates both methods for controlling
+ resources.</para>
+
+ <sect2 xml:id="users-limiting">
+ <title>Login Classes</title>
+
+ <indexterm>
+ <primary>limiting users</primary>
+ </indexterm>
+ <indexterm>
+ <primary>accounts</primary>
+ <secondary>limiting</secondary>
+ </indexterm>
+
+ <para>&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.</para>
+
+ <indexterm>
+ <primary>quotas</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>quotas</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>disk quotas</primary>
+ </indexterm>
+
+ <para>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
+ <xref linkend="quotas"/>.</para>
+
+ <para>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.</para>
+
+ <indexterm>
+ <primary><filename>/etc/login.conf</filename></primary>
+ </indexterm>
+
+ <para>Login classes are defined in
+ <filename>/etc/login.conf</filename> and are described in
+ detail in &man.login.conf.5;. Each user account is assigned
+ to a login class, <literal>default</literal> by default, and
+ each login class has a set of login capabilities associated
+ with it. A login capability is a
+ <literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>
+ pair, where <replaceable>name</replaceable> is a well-known
+ identifier and <replaceable>value</replaceable> is an
+ arbitrary string which is processed accordingly depending on
+ the <replaceable>name</replaceable>. Setting up login classes
+ and capabilities is rather straightforward and is also
+ described in &man.login.conf.5;.</para>
+
+ <note>
+ <para>&os; does not normally read the configuration in
+ <filename>/etc/login.conf</filename> directly, but instead
+ reads the <filename>/etc/login.conf.db</filename> database
+ which provides faster lookups. Whenever
+ <filename>/etc/login.conf</filename> is edited, the
+ <filename>/etc/login.conf.db</filename> must be updated by
+ executing the following command:</para>
+
+ <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
+ </note>
+
+ <para>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.</para>
+
+ <para>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;.</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><literal>coredumpsize</literal></term>
+
+ <listitem>
+ <para>The limit on the size of a core file
+ <indexterm>
+ <primary>coredumpsize</primary>
+ </indexterm>
+ generated by a program is subordinate to other limits
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>coredumpsize</secondary>
+ </indexterm>
+ on disk usage, such as <literal>filesize</literal>, 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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>cputime</literal></term>
+
+ <listitem>
+ <para>The maximum amount of CPU
+ <indexterm>
+ <primary>cputime</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>cputime</secondary>
+ </indexterm>
+ time a user's process may consume. Offending processes
+ will be killed by the kernel.</para>
+
+ <note>
+ <para>This is a limit on CPU <emphasis>time</emphasis>
+ consumed, not percentage of the CPU as displayed in
+ some fields by &man.top.1; and &man.ps.1;.</para>
+ </note>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>filesize</literal></term>
+
+ <listitem>
+ <para>The maximum size of a file
+ <indexterm>
+ <primary>filesize</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>filesize</secondary>
+ </indexterm>
+ the user may own. Unlike
+ <link linkend="quotas">disk quotas</link>, this limit is
+ enforced on individual files, not the set of all files a
+ user owns.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>maxproc</literal></term>
+
+ <listitem>
+ <para>The maximum number of processes
+ <indexterm>
+ <primary>maxproc</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>maxproc</secondary>
+ </indexterm>
+ a user can run. This includes foreground and background
+ processes. This limit may not be larger than the system
+ limit specified by the <varname>kern.maxproc</varname>
+ &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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>memorylocked</literal></term>
+
+ <listitem>
+ <para>The maximum amount of memory
+ <indexterm>
+ <primary>memorylocked</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>memorylocked</secondary>
+ </indexterm>
+ 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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>memoryuse</literal></term>
+
+ <listitem>
+ <para>The maximum amount of memory
+ <indexterm>
+ <primary>memoryuse</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>memoryuse</secondary>
+ </indexterm>
+ 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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>openfiles</literal></term>
+
+ <listitem>
+ <para>The maximum number of files a process may have open
+ <indexterm>
+ <primary>openfiles</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>openfiles</secondary>
+ </indexterm>.
+ 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
+ <varname>kern.maxfiles</varname> &man.sysctl.8;.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>sbsize</literal></term>
+
+ <listitem>
+ <para>The limit on the amount of network memory, and
+ thus mbufs
+ <indexterm>
+ <primary>sbsize</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>sbsize</secondary>
+ </indexterm>,
+ a user may consume. This can be generally used to limit
+ network communications.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>stacksize</literal></term>
+
+ <listitem>
+ <para>The maximum size of a process stack
+ <indexterm>
+ <primary>stacksize</primary>
+ </indexterm>
+ <indexterm>
+ <primary>limiting users</primary>
+ <secondary>stacksize</secondary>
+ </indexterm>.
+ 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.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>There are a few other things to remember when setting
+ resource limits. Following are some general tips,
+ suggestions, and miscellaneous comments.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Processes started at system startup by
+ <filename>/etc/rc</filename> are assigned to the
+ <literal>daemon</literal> login class.</para>
+ </listitem>
+
+ <listitem>
+ <para>Although the <filename>/etc/login.conf</filename> 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.</para>
+ </listitem>
+
+ <listitem>
+ <para>Users of <application>&xorg;</application> should
+ probably be granted more resources than other users.
+ <application>&xorg;</application> by itself takes a lot of
+ resources, but it also encourages users to run more
+ programs simultaneously.</para>
+ </listitem>
+
+ <listitem>
+ <para>Many limits apply to individual processes, not the
+ user as a whole. For example, setting
+ <varname>openfiles</varname> 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
+ <literal>openfiles</literal> multiplied by the value of
+ <literal>maxproc</literal>. This also applies to memory
+ consumption.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>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;.</para>
+ </sect2>
+
<sect2>
<title>Enabling and Configuring Resource Limits</title>
More information about the svn-doc-head
mailing list