From owner-freebsd-questions@FreeBSD.ORG Fri Feb 11 20:37:47 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0BDF16A4CE for ; Fri, 11 Feb 2005 20:37:47 +0000 (GMT) Received: from clunix.cl.msu.edu (clunix.cl.msu.edu [35.9.2.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48BA343D46 for ; Fri, 11 Feb 2005 20:37:47 +0000 (GMT) (envelope-from jerrymc@clunix.cl.msu.edu) Received: (from jerrymc@localhost) by clunix.cl.msu.edu (8.11.7p1+Sun/8.11.7) id j1BKbjm00322; Fri, 11 Feb 2005 15:37:45 -0500 (EST) From: Jerry McAllister Message-Id: <200502112037.j1BKbjm00322@clunix.cl.msu.edu> To: cmorland@gmail.com Date: Fri, 11 Feb 2005 15:37:44 -0500 (EST) In-Reply-To: <8ca932905021112136ad00369@mail.gmail.com> from "Chad Morland" at Feb 11, 2005 03:13:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: /tmp on same partition as / X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 20:37:47 -0000 > > I'm setting up a mail server at the momment, one of the things that I > forgot to do was create /tmp as a separate partiton (/ = 2gb). There > will be no user logins to the machine aside from admins and the only > thing that it will run is qmail acting as a smarthost (vanilla qmail, > no amavis or anything of the sort.) > > In your opinion is having /tmp on the same partition as / really THAT > bad in this case? I'm just wondering cause some people have mentioned > that its a major security risk. Really, I don't think it is for what > this box is doing. I suppose it could have some security implications, but it is not so much a security risk as a potential functional problem. It is possible for something to begin writing an unexpectedly large amount of stuff to /tmp. If it is a separate file system, then that process will die or at least get stuck waiting when /tmp fills up. It could also affect any other processes trying to use /tmp for scratch space too. But, if you catch it reasonably soon, you can usuall just go in a nuke some unnecessary files and it will clean up OK. But, if it is in the root file system that means that root will get filled up. That makes it much more likely that the system will come to a grinding halt and be harder, probably impossible, to clean things up without taking the system down and mucking around in single user. ////jerry > > -CM