From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4484 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: install.sh is wrong with libc.so Date: Wed, 15 Jan 2014 11:01:39 +0000 Message-ID: <52D66A93.8030608@skarnet.org> References: <5905c9fb-9fc8-4cf1-ac29-ed830c8ae5a1@email.android.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389783697 23496 80.91.229.3 (15 Jan 2014 11:01:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 11:01:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4488-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 15 12:01:44 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1W3OEB-0003kC-DG for gllmg-musl@plane.gmane.org; Wed, 15 Jan 2014 12:01:43 +0100 Original-Received: (qmail 26373 invoked by uid 550); 15 Jan 2014 11:01:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26365 invoked from network); 15 Jan 2014 11:01:42 -0000 X-SourceIP: 79.97.22.118 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <5905c9fb-9fc8-4cf1-ac29-ed830c8ae5a1@email.android.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4484 Archived-At: > umask 077 > cat < lib/libc.so > /lib/libc.so.tmp.pid # /lib/libc.so.tmp.pid is created with mode 600 > mv -f /lib/libc.so.tmp.pid /lib/libc.so > chmod 755 /lib/libc.so # failed with "Permission denied" Very funny bug ^^ I'm curious of the thought process behind that code: - why cat instead of cp ? I guess it's to avoid the implementation-defined behaviour of cp wrt. rights of the destination file, whereas >'s behaviour is guaranteed. - but an explicit chmod is needed anyway. - why perform the chmod after the mv, since mv is guaranteed to be a rename() in that case, the rights will be preserved ? Is there a possibility of someone abusing the temp file if it is 0755, knowing it is owned by root anyway ? chmoding the temp file before the mv -f, instead of /lib/libc.so at the end, looks like the obvious and simplest fix, but I'm wondering whether I missed something. -- Laurent