From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 17:44:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C427016A41F for ; Tue, 2 Aug 2005 17:44:49 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 527CC43D55 for ; Tue, 2 Aug 2005 17:44:49 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id BEEB42B4E6; Tue, 2 Aug 2005 12:44:48 -0500 (CDT) Date: Tue, 2 Aug 2005 12:44:45 -0500 From: Craig Boston To: diz@linuxpowered.com Message-ID: <20050802174445.GA47508@nowhere> Mail-Followup-To: Craig Boston , diz@linuxpowered.com, vd@datamax.bg, freebsd-hackers@freebsd.org References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, vd@datamax.bg Subject: Re: [patch] rc.d/tmp (silly mkdir usage) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2005 17:44:49 -0000 On Tue, Aug 02, 2005 at 11:47:19AM -0500, diz@linuxpowered.com wrote: > Well these notions have nothing todo with the way it works, but they are > interesting still. I would imagine a dir could be linked too if somebody > managed to insert a rc.d script in that was ordered sufficiently early > enough to do the evil tasks you are thinking about. Even if mktemp(1) were > available at this stage, I wouldn't use it here. A link could also be left over from before the boot. rc.d/tmp runs before cleartmp. > Let me be clear about this, the ONLY reason mkdir is used here is > because touch is under /usr somewhere which isn't even mounted at this > point (assuming /usr is mounted seperatly, as is the case on nfs > diskless systems). No, touch has different behavior than mkdir. Whether it was done intentionally or just happens to be the case because /usr is not available, mkdir is the most secure and robust way to go, because it covers all of the cases: 1) /tmp/.diskless doesn't exist -> A directory .diskless is created, which is then removed 2) /tmp/.diskless is a link to a file -> mkdir fails because "File exists" 3) /tmp/.diskless is a link to a directory -> mkdir succeeds but does nothing because -p was specified. The link is then removed. 4) /tmp/.diskless is a link to a nonexistent path or name -> mkdir fails (even with -p) because it can't follow the link: "No such file or directory" 5) /tmp/.diskless exists and is a file -> mkdir fails: "File exists" 6) /tmp/.diskless exists and is a directory -> mkdir succeeds. Later, /tmp/.diskless is removed _only_ if it is empty. Even though touch doesn't change file contents, it could potentially be abused to change the timestamp on an arbitrary file if a link were left in /tmp. The only way to securely use touch or ">" would be to rm -f /tmp/.diskless first, and that is a potentially destructive operation on the off chance the administrator created a file called /tmp/.diskless. It's a very remote chance yes, but why Creating a file called that may cause undesired effects such as mounting an mfs /tmp when you didn't want one, but it won't cause any data loss. > So we are left with what is availabile in /bin, /sbin, /rescue. > Therefore mkdir was used as a work-around. What I'm saying is this > entire thought process is overly-engineered when the shell can simply > "touch" a file with stdout or stderr. This is indeed the most minor of > optimizations. It's not a minor optimization if it changes the semantics of what happens. > is very dangerous because it could nuke a random file if a symlink exists. Even >> or touch can mess with timestamps or create files that don't exist, all with the power of root. Craig