From owner-freebsd-current Sat Apr 10 13:32:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id 2A28314C0D for ; Sat, 10 Apr 1999 13:32:32 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id NAA08796; Sat, 10 Apr 1999 13:30:02 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199904102030.NAA08796@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Dmitry Valdov , Brian Feldman , freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) In-reply-to: Your message of "Sat, 10 Apr 1999 13:11:45 PDT." <199904102011.NAA01133@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Apr 1999 13:30:02 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It should be possible to prevent a user from hogging a system if the system's naive scheduler is improved. Amancio > It is not possible to prevent a user from hogging the cpu on the system. > What you *CAN* do is make it difficult for the user to crash the system > by limiting the number of processes he is allowed to run, the maximum > data segment size each process is allowed to allocate, and by placing > quotas on disk partitions he has write access to. This allows a > sysop to get on the system and blow the idiot user away without having > to reboot. > > cpu utilization has nothing to do with system cpu verses user cpu. cpu > is cpu. One process can hog the cpu, it doesn't really matter whether > it is supervisor or user mode cpu. The system will attempt to balance > cpu utilization when several processes need cpu. The worst a user can > do cpu-wise is to start N cpu-bound processes. > > Starting N cpu-bound processes will drive the load up on the machine, but > as long as N is limited it will not prevent a sysop from getting in there > and taking out the user. > > You don't give user accounts away to people who you think might > try to crash the system, so resource limits are mostly there to prevent > users making stupid mistakes from taking the system down with them. > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message