From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 30 15:56:08 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6D5A16A402 for ; Tue, 30 Jan 2007 15:56:08 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.freebsd.org (Postfix) with SMTP id 7EC3B13C441 for ; Tue, 30 Jan 2007 15:56:08 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 96596 invoked by uid 1001); 30 Jan 2007 15:56:46 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Tue, 30 Jan 2007 10:56:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17855.27326.236882.38629@bhuda.mired.org> Date: Tue, 30 Jan 2007 10:56:46 -0500 To: waldeck@gmx.de In-Reply-To: <20070130140227.26613101832@hk2.uwaterloo.ca> References: <20070130140227.26613101832@hk2.uwaterloo.ca> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: top delay value X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2007 15:56:08 -0000 In <20070130140227.26613101832@hk2.uwaterloo.ca>, waldeck@gmx.de typed: > An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). No, they can't. Should they use the interactive facility to set the delay to 0 (you can't do that via the -s switch), then top will compete evenly with normal users processes until it accumulates enough CPU that the scheduler changes it's nice value. It then no longer competes with normal user processes for CPU. At that point, the CPU cyles it's "wasting" are mostly cycles that would have been "wasted" in an idle loop anyway. Generally (but not always), there's no real reason to care about such. > Is there any possibility to deactivate this functionality without recompilation? chmod 0 /usr/bin/top > There are other top implementations that use a "secure mode" configuration > which avoids the setting of the delay value for unprivileged users. There are *lots* of commands on the system that can be coerced into spinning on the CPU doing nothing, starting with /bin/sh. The correct place to deal with this issue is in the kernel scheduler, so you can do it once and for all. That said, there may be a use case where you want a top display to be available without the interactive commands being available, ala the "secure mode" you mention. That can be provided with a little work, depending on the exact goals. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.