From owner-cvs-all Mon Jun 21 20:16: 2 1999 Delivered-To: cvs-all@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 2A18515066; Mon, 21 Jun 1999 20:15:43 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id MAA02825; Tue, 22 Jun 1999 12:45:40 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA04481; Tue, 22 Jun 1999 12:46:50 +0930 Date: Tue, 22 Jun 1999 12:46:49 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Peter Wemm Cc: "Brian F. Feldman" , Jean-Marc Zucconi , hoek@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern imgact_gzip.c In-Reply-To: <19990622030346.622EA75@overcee.netplex.com.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Tue, 22 Jun 1999, Peter Wemm wrote: > Ahh yes, I forgot that / was read-write for MFS boots. However: > > #!/bin/sh > skip=18 > if /usr/bin/tail +$skip $0 | gzip -cd > /tmp/gztmp$$; then > chmod 700 /tmp/gztmp$$ > prog="`echo $0 | sed 's|^.*/||'`" > if /bin/ln /tmp/gztmp$$ "/tmp/$prog" 2>/dev/null; then > trap '/bin/rm -f /tmp/gztmp$$ "/tmp/$prog"; exit $res' 0 > (/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ "/tmp/$prog") 2>/dev/null & > /tmp/"$prog" ${1+"$@"}; res=$? > else > trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0 > (/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2>/dev/null & > /tmp/gztmp$$ ${1+"$@"}; res=$? > fi > else > echo Cannot decompress $0; exit 1 > fi; exit $res This is the unpatched (insecure) version of gzexe (all the /tmp/gztmp$$'s), but it's functionally the same. > Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd > crunched linked binary, how is it supposed to decompress itself? "sh" itself > is part of the crunched binary, so what is going to decode sh when sh itself > is a shell script? Yes, that seems to be a problem - gzexe depends on those executables. However it shouldn't be too hard to recode this decompressor in C to perform the same job without any external dependencies. The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. Kris > Cheers, > -Peter ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message