From owner-freebsd-doc@FreeBSD.ORG Sat Feb 2 04:04:58 2013 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFD2DF8D for ; Sat, 2 Feb 2013 04:04:58 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by mx1.freebsd.org (Postfix) with ESMTP id D1ED2DF1 for ; Sat, 2 Feb 2013 04:04:58 +0000 (UTC) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id D972B36006A for ; Fri, 1 Feb 2013 20:04:51 -0800 (PST) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 8BAB0360014 for ; Fri, 1 Feb 2013 20:04:51 -0800 (PST) Date: Fri, 1 Feb 2013 23:04:50 -0500 From: Tom Rhodes To: doc@FreeBSD.org Subject: [REVIEW REQUEST]: rctl section Message-Id: <20130201230450.46255f5e.trhodes@FreeBSD.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 04:04:59 -0000 Hi team, Long time, no chat. It's been awhile, so I would like to get some review on this section. In this case, I have used some generic results (testing them with a forkbomb, smart, I know) and I would like to get some pre-commit feedback. Thanks in advance to anyone who loans me a few moments of their time! -- Tom Rhodes Index: security/chapter.xml =================================================================== --- chapter.xml (revision 40807) +++ chapter.xml (working copy) @@ -97,6 +97,11 @@ Have an idea of what Process Accounting is and how to enable it on &os;. + + + Understand what the resource limits database and + how to utilize it to excerpt more control over users. + Before reading this chapter, you should: @@ -4149,4 +4154,116 @@ pages. + + + + + + Tom + Rhodes + Contributed by + + + + + Resource limits + + + Resource limits + + + For years, &os; has made use of a resource limits + database controlled through a flat file + /etc/login.conf. While it has + been discussed previously and is still supported, it + is not the most optimal method of controlling resources. + The flat file requires users to be divided into various + group labels known as classes, which require changes not + only to this flat file but also the password database. + Potentially, a single, more constrained user would require + an additional label added, the resource database needs to be + built using cap_mkdb, along with edits to + the /etc/master.passwd file. In + addition, the password database will also need rebuilt using + pwd_mkdb. This multi-step process could be + very time consuming depending on how many users must be + singled out. + + A new command in &os;, &man.rctl.8;, allows for a more + fine grained method of controlling resources limits for + users. This command will support much more than users, + it will also set resource constraints on processes, jails, + and the original login class. These advanced features + provide administrators and users with methods to control + resources through the command line and set rules on + system initialization using a configuration + file. + + To enable this feature, add the following lines to + GENERIC, or the custom kernel + configuration file, and rebuild.: + + options RACCT +options RCTL + + Due to the nature of this configuration file, the + entire system will need rebuilt. See , which will provide instructions for + this process. Once this is complete, the rctl + may be used to set rules for the system. + + Rule syntax is simple, controlled through the use of + a subject, a subject-id, resource, and action. Take the + following example rule: + + user:trhodes:maxproc:deny=10/user + + This rule shows a basic premise of a rule, here the + subject is user and the subject-id + is trhodes. The maxproc is, of course, + max number of processes, which is considered the action. + The action here is set to deny, which blocks any new + processes from being created. Other actions could be + log to the console, pass a notification to &man.devd.8;, or + send a sigterm to the process. + + Some care must be taken while adding rules, the one above + will unfortunately block me from doing the most simple tasks + after I have logged in and executed a screen + session. When a resource limit has been hit, an error will + be printed, as in this example: + + &prompt.user; man test + /usr/bin/man: Cannot fork: Resource temporarily unavailable +eval: Cannot fork: Resource temporarily unavailable + + For another example, &man.rctl.8; could be used to prevent + a jail from exceeding a memory limit. This rule could be + written as: + + &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail + + Rules may also persist across reboots if they have been + added to the /etc/rctl.conf file. The + format is a rule, without the preceding command. For example, + the previous rule could be added like the following: + + # Block jail from using more than 2G memory: +jail:httpd:memoryuse:deny=2G/jail + + To remove a rule, just ask rctl to + remove it from the list: + + &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user + + The manual page shows a method for removing all rules; + however, if removing all rules for a single user is required, + the following command may be issued: + + &prompt.root; rctl -r user:trhodes + + Many other resources exist which could be used to excerpt + additional control over subjects. See the manual page for + rctl to learn about them. +