From owner-svn-doc-all@FreeBSD.ORG Wed Apr 30 14:45:09 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB404AD4; Wed, 30 Apr 2014 14:45:09 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6A0B1A35; Wed, 30 Apr 2014 14:45:09 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3UEj9cb080621; Wed, 30 Apr 2014 14:45:09 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3UEj9ug080619; Wed, 30 Apr 2014 14:45:09 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404301445.s3UEj9ug080619@svn.freebsd.org> From: Dru Lavigne Date: Wed, 30 Apr 2014 14:45:09 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44718 - in head/en_US.ISO8859-1/books/handbook: basics security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:45:09 -0000 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 - - 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 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 @@ - 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