From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 2 16:48:55 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 5322B16A41F for ; Tue, 2 Aug 2005 16:48:55 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from terrence.linuxpowered.com (terrence.linuxpowered.com [70.85.29.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4566B43D5F for ; Tue, 2 Aug 2005 16:48:48 +0000 (GMT) (envelope-from diz@linuxpowered.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by terrence.linuxpowered.com (Postfix) with ESMTP id 54974264279; Tue, 2 Aug 2005 11:47:22 -0500 (CDT) Received: from terrence.linuxpowered.com ([127.0.0.1]) by localhost (terrence.linuxpowered.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21477-02; Tue, 2 Aug 2005 11:47:20 -0500 (CDT) Received: from secure.linuxpowered.com (www.vpisystems.com [70.85.29.100]) by terrence.linuxpowered.com (Postfix) with ESMTP id D1CEF264053; Tue, 2 Aug 2005 11:47:19 -0500 (CDT) Received: from 68.95.232.238 (SquirrelMail authenticated user diz@linuxpowered.com); by secure.linuxpowered.com with HTTP; Tue, 2 Aug 2005 11:47:19 -0500 (CDT) Message-ID: <1711.68.95.232.238.1123001239.squirrel@68.95.232.238> In-Reply-To: <20050802062937.GA31485@sinanica.bg.datamax> References: <51934.68.95.232.238.1122957425.squirrel@68.95.232.238> <20050802062937.GA31485@sinanica.bg.datamax> Date: Tue, 2 Aug 2005 11:47:19 -0500 (CDT) From: diz@linuxpowered.com To: vd@datamax.bg User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at phpcult.com Cc: freebsd-hackers@freebsd.org 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 16:48:55 -0000 > On Mon, Aug 01, 2005 at 11:37:05PM -0500, diz@linuxpowered.com wrote: >> Howdy hackers, >> >> I'm sorry for the previous patch, so here is at least one item that >> really >> bugs me that isn't obfuscation. In short, I don't see any reason to fork >> some process to simply "touch" a file (is a filesystem writable) when >> built-in shell i/o does this: >> >> --- /etc/rc.d/tmp.orig Mon Aug 1 23:20:24 2005 >> +++ /etc/rc.d/tmp Mon Aug 1 23:22:07 2005 >> @@ -48,8 +48,8 @@ >> [Nn][Oo]) >> ;; >> *) >> - if (/bin/mkdir -p /tmp/.diskless 2> /dev/null); then >> - rmdir /tmp/.diskless >> + if ( > /tmp/.diskless 2> /dev/null); then >> + rm /tmp/.diskless >> else >> if [ -h /tmp ]; then >> echo "*** /tmp is a symlink to a non-writable >> area!" >> > > The thing you suggest is bloody insecure. Just imagine some baduser > doing ln -s /etc/passwd /tmp/.diskless before rc.d/tmp gets executed. > I guess this is the reason why directory creation is used instead of > file creation. 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. > > I just wonder why a new shell is forked for this test. Simply > if /bin/mkdir -p /tmp/.diskless 2> /dev/null ; then > would do the same thing without forking a new shell that only executes > /bin/mkdir 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). 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. > > Even we can use > if [ -d /tmp -a -w /tmp ] ; then > or (which is equivalent) > if [ -d /tmp ] && [ -w /tmp ] ; then > and save external commands (mkdir) execution and directory > creation/deletion at all. >