From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 10 08:49:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A83AA89 for ; Tue, 10 Jun 2014 08:49:55 +0000 (UTC) Received: from server1.xenet.de (server1out.xenet.de [213.221.94.200]) by mx1.freebsd.org (Postfix) with ESMTP id CB0B92A26 for ; Tue, 10 Jun 2014 08:49:52 +0000 (UTC) Received: from [10.0.0.32] (intern.xenet.de [213.221.94.50]) (authenticated bits=0) by server1.xenet.de (8.12.5/8.12.5) with ESMTP id s5A8neBJ009539 for ; Tue, 10 Jun 2014 10:49:43 +0200 (CEST) (envelope-from meyser@xenet.de) Message-ID: <5396C6A3.6050004@xenet.de> Date: Tue, 10 Jun 2014 10:49:39 +0200 From: Matthias Meyser Organization: XeNET GmbH, Clausthal-Zellerfeld User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [RFC] Fixed installworld with noexec /tmp References: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> In-Reply-To: <25659df71b49c7b72b6f2d9a786c5ac9@shatow.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.38 X-Mailman-Approved-At: Tue, 10 Jun 2014 11:29:06 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 08:49:55 -0000 Hi Am 10.06.2014 01:01, schrieb Bryan Drewery: > I've always had my /tmp mounted as noexec. Despite how useless this > is, I and many others have had trouble with installworld due to it. > > You can see how frequent it occurs here: > https://www.google.com/#q=freebsd+installworld+noexec > > A simple workaround, which I only just discovered from PR 58117, is to set > TMPDIR > to somewhere that can exec. > > This patch fixes it by using the OBJDIR rather than the assumed /tmp or > TMPDIR. > > The purpose of the installworld code using INSTALLTMP is to use the pre-install > binaries to do the install, rather than the newly built binaries. This is to > ensure > the binaries will run while system is in an inconsistent state with > libraries and > in case the kernel is not yet upgraded. My change adds continues to respect > that by > ensuring it uses the already-installed mkdir(1) and env(1) with full paths. > > http://people.freebsd.org/~bdrewery/patches/installworld-noexec.txt > > --- Makefile.inc1 > +++ Makefile.inc1 > @@ -191,7 +191,9 @@ TMPPATH= ${STRICTTMPPATH}:${PATH} > # when in the middle of installing over this system. > # > .if make(distributeworld) || make(installworld) > -INSTALLTMP!= /usr/bin/mktemp -d -u -t install > +INSTALLTMPDIR= ${OBJTREE}${.CURDIR}/itmp > +INSTALLTMP!= /bin/mkdir -p ${INSTALLTMPDIR} && /usr/bin/env \ > + TMPDIR=${INSTALLTMPDIR} /usr/bin/mktemp -d -u -t install > .endif > > # > @@ -833,7 +835,7 @@ distributeworld installworld: _installcheck_world > LOCAL_MTREE=${LOCAL_MTREE:Q} distrib-dirs > .endif > ${_+_}cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}; \ > - ${IMAKEENV} rm -rf ${INSTALLTMP} > + ${IMAKEENV} rm -rf ${INSTALLTMPDIR} > .if make(distributeworld) > .for dist in ${EXTRA_DISTRIBUTIONS} > find ${DESTDIR}/${DISTDIR}/${dist} -mindepth 1 -empty -delete > > The only downside I see is that failures can leave the stale tmpdir in > the OBJDIR, which is why I remove the entire "itmp" dir once installworld > finally does succeed. > Would this not break installing from an "RO" mounted OBJDIR? We build everything on one machine an install on many machines by nfsmounting /usr/src/, /usr/doc, /usr/obj. All of them are mounted "RO" to prevent changes during install. BW Matthias -- Matthias Meyser | XeNET GmbH Tel.: +49-5323-9489050 | 38678 Clausthal-Zellerfeld, Marktstrasse 40 Fax: +49-5323-9489059 | Registergericht: Amtsgericht Braunschweig HRB 110823 Email: Meyser@xenet.de | Geschaeftsfuehrer: Matthias Meyser