Date: Wed, 27 Feb 2002 11:04:11 +1100 From: Andrew Johns <johnsa@kpi.com.au> To: Roger Marquis <marquis@roble.com> Cc: security@FreeBSD.ORG Subject: Re: Third /tmp location ? (and maybe a fourth too) Message-ID: <3C7C227B.9020100@kpi.com.au> References: <20020226152847.L25859-100000@roble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C7C227B.9020100>