From owner-freebsd-security Tue Feb 26 16: 4:36 2002 Delivered-To: freebsd-security@freebsd.org Received: from www.kpi.com.au (www.kpi.com.au [203.39.132.210]) by hub.freebsd.org (Postfix) with ESMTP id 6053B37B417 for ; Tue, 26 Feb 2002 16:04:23 -0800 (PST) Received: from kpi.com.au (localhost.kpi.com.au [127.0.0.1]) by www.kpi.com.au (8.9.3/8.9.3) with ESMTP id LAA54931; Wed, 27 Feb 2002 11:16:58 +1100 (EST) (envelope-from johnsa@kpi.com.au) Message-ID: <3C7C227B.9020100@kpi.com.au> Date: Wed, 27 Feb 2002 11:04:11 +1100 From: Andrew Johns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-gb MIME-Version: 1.0 To: Roger Marquis Cc: security@FreeBSD.ORG Subject: Re: Third /tmp location ? (and maybe a fourth too) References: <20020226152847.L25859-100000@roble.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Roger Marquis wrote: >>> File system full errors are typically caused by >>> unnecessary partitioning. You rarely see them on >>> single-partition systems. Creating symlinks or >>> additional tmp directories to avoid the inevitable >>> drawback of excess partitions is two bads, which don't sum >>> to a good. Both also violate the KIS principle. >>> >> Unfortunately, as demonstrated in another reply, the >> optimal partition scheme (/, /usr, /var) is preferred over >> single partition schemes. >> > > Preferred by who? Not by the majority of admins I've worked > with over the past couple of decades. Neither is there any > real gain afforded by a read-only /usr. /usr had to be > partitioned years ago because it wouldn't fit on the root > disk. With the introduction of 1GB disks there is no longer > a good reason to partition /usr though some still > rationalize the practice citing unsubstantiated benefits of > read-only mounts vs read-only permissions. It's called Defense in Depth, IIRC. Rather than "r/o mounts vs r/o permissions", it should be "r/o mounts AND r/o perms" to afford the greatest depth, although neither of these methods stop anything once someone has root - it will just take them that little bit longer to get around it (even if only seconds - note:I'm in agreement that it's basically unsubstantiated, however see below). > > Creating a partition for /var is also rarely necessary unless > your applications require partitioning for performance , > pseudo-quotas, or they need more disk than the root volume > provides. > I remember once seeing a system fill /var with a runaway process that crashed overnight. Unfortunately all on one partition. System emailed support, they dialled in to fix. Their dial-up password had expired, they were prompted for new one, system removed passwd file to update, runaway process saw the free space and immediately filled it: => nowhere to write new passwd files! => passwd files empty => no users could log in. => no terminals logged in as root (policy), but there were 600 users already in... I had to pull the plug to reboot it. This was for a bank and they ran for a whole day (bank terminals stay logged into unix account but with PICK application f/end) without any new logins. Having something fill a separately mounted /var would never cause this problem... Just a few cents worth... Cheers AJ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message