From owner-freebsd-bugs@FreeBSD.ORG Wed May 2 00:50:05 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3377E16A408 for ; Wed, 2 May 2007 00:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 466DB13C45B for ; Wed, 2 May 2007 00:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l420o4eS065575 for ; Wed, 2 May 2007 00:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l420o48J065574; Wed, 2 May 2007 00:50:04 GMT (envelope-from gnats) Resent-Date: Wed, 2 May 2007 00:50:04 GMT Resent-Message-Id: <200705020050.l420o48J065574@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "John E. Hein" Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 110A616A402 for ; Wed, 2 May 2007 00:46:13 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (daffy.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id CA18813C489 for ; Wed, 2 May 2007 00:46:12 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id l420BDND048164; Tue, 1 May 2007 18:11:13 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.13.8/8.13.8) with ESMTP id l420BCUb051836; Tue, 1 May 2007 18:11:13 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.13.8/8.13.8/Submit) id l420BC2t051835; Tue, 1 May 2007 18:11:12 -0600 (MDT) (envelope-from jhein) Message-Id: <200705020011.l420BC2t051835@gromit.timing.com> Date: Tue, 1 May 2007 18:11:12 -0600 (MDT) From: "John E. Hein" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: jhein@timing.com Subject: bin/112336: install -S (safe copy) with -C or -p is not so safe X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 00:50:05 -0000 >Number: 112336 >Category: bin >Synopsis: install -S (safe copy) with -C or -p is not so safe >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed May 02 00:50:03 GMT 2007 >Closed-Date: >Last-Modified: >Originator: John E. Hein >Release: FreeBSD 6.2-STABLE i386 >Organization: Symmetricom, Inc. >Environment: System: FreeBSD gromit.timing.com 6.2-STABLE FreeBSD 6.2-STABLE #2: Wed Mar 21 09:48:47 MDT 2007 jhein@gromit.timing.com:/usr/obj/usr/src/sys/GROMIT i386 >Description: When using install -S, in certain cases, install will unlink the destination file defeating the point of using -S. fred & joe are both in the operator group % su - fred % mkdir /tmp/dest % chgrp operator /tmp/dest % chmod 775 /tmp/dest % touch foo % install -S -C -m 0755 foo /tmp/dest % ls -l /tmp/dest/foo -rwxr-xr-x 1 joe operator 0 Apr 27 18:02 /tmp/dest/foo* % su - joe % touch foo % install -S -C -m 0644 foo /tmp/dest install: /tmp/dest/foo: chmod: Operation not permitted % ls /tmp/dest/foo ls: /tmp/dest/foo: No such file or directory There are other ways to recreate this. For instance, if the files compare the same [1], and the user can write in the directory, but the file has the wrong ownership (as opposed to the wrong perms shown above), for instance. [1] per the content comparison done by compare() in usr.bin/xinstall/xinstall.c This happens when -C or -p is used and the file content is the same. Then the creation of the temp file used by -S is skipped and the chown/chmod is attempted directly on the destination file. Side issue: ----------- I'm not really sure what the rationale is for unlink(2)-ing the file if the chmod/chown fails. It was surprising to me to have the file deleted if the chmod fails (even without -S), but that's been in xinstall.c since 1.1. I'd be inclined to remove the unlink(2) in these cases, but that might be break POLA for some, and I may have not considered cases where it might be useful or expected (are there any?). In any case, that's a separate bug. >How-To-Repeat: See above. >Fix: There are at least a couple ways to fix the disappearing file issue when using safe copy mode: 1) Always operate on the temp file with -S. If you have any errors unlink the temp file rather than the target file. pros: You create the file from scratch, so you will have no problems with chmod on a file you own. cons: You lose speedup if file content is the same. You can't chmod the dest file in place, so if you don't have write perms on the dir, it will fail (but that should be expected since it is documented that -S needs to write in the directory, so this is a minor con, IMO - but install(1) should probably talk about directory perms for -S) 2) If the files compare identically, check the perms/ownership, and if chown/chmod needs to be run, fall back to creating the temp file (maybe do the perms/ownership check first since that will be faster than content comparison). pros: You don't waste time creating a temp file if not needed. cons: Code complexity. I'm trying to decide which of 1 or 2 to do in a patch. If there is a better way, let me know. >Release-Note: >Audit-Trail: >Unformatted: