Date: Tue, 26 Feb 2002 19:21:37 -0500 From: Zvezdan Petkovic <zvezdan@CS.WM.EDU> To: security@FreeBSD.ORG Subject: Re: Third /tmp location ? (and maybe a fourth too) Message-ID: <20020226192137.A22734@dali.cs.wm.edu> In-Reply-To: <3C7C227B.9020100@kpi.com.au>; from johnsa@kpi.com.au on Wed, Feb 27, 2002 at 11:04:11AM %2B1100 References: <20020226152847.L25859-100000@roble.com> <3C7C227B.9020100@kpi.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 27, 2002 at 11:04:11AM +1100, Andrew Johns wrote: > 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). > system running from CDROM would do the job. A hacker cannot change /usr/bin/passwd runnning from CDROM. > > > > > 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... > Excellent example. But as I said before, there are two irreconcilable shools of thought on this. I tend to be more practical and flexible than dogmatic. Depending on circumstances and requirements, both choices can be good. -- Zvezdan Petkovic <zvezdan@cs.wm.edu> http://www.cs.wm.edu/~zvezdan/ 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?20020226192137.A22734>