From owner-freebsd-ports@FreeBSD.ORG Wed Mar 1 21:06:04 2006 Return-Path: X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA19E16A420; Wed, 1 Mar 2006 21:06:04 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51D3E43D46; Wed, 1 Mar 2006 21:06:04 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id ECF41388E82; Wed, 1 Mar 2006 15:06:03 -0600 (CST) Date: Wed, 01 Mar 2006 15:06:03 -0600 From: Paul Schmehl To: Kris Kennaway Message-ID: In-Reply-To: <20060301203540.GA29563@xor.obsecurity.org> References: <44050D77.2030503@j2d.lam.net.au> <84747890@srv.sem.ipt.ru> <4405F6F0.9050703@FreeBSD.org> <665EA8A520757A68F0485536@utd59514.utdallas.edu> <20060301203540.GA29563@xor.obsecurity.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ports@FreeBSD.org, Sergey Matveychuk Subject: Re: FreeBSD Port: mpack-1.6 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 21:06:04 -0000 --On Wednesday, March 01, 2006 15:35:40 -0500 Kris Kennaway wrote: > On Wed, Mar 01, 2006 at 02:08:22PM -0600, Paul Schmehl wrote: > >> So the chances of overwriting a file with the same random char set is >> close to nil. > > Close to nil != nil. > > I haven't read the code here, but secure handling of temp files > requires care. The code should just use mkstemp() though. > That's included in the patches. That was one that Sergey added after I submitted the update. I have now included it in the (new) patch. --- unixpk.c.orig Wed Mar 1 09:28:13 2006 +++ unixpk.c Wed Mar 1 09:31:09 2006 @@ -164,10 +164,10 @@ strcpy(fnamebuf, getenv("TMPDIR")); } else { - strcpy(fnamebuf, "/usr/tmp"); + strcpy(fnamebuf, "/tmp"); } strcat(fnamebuf, "/mpackXXXXXX"); - mktemp(fnamebuf); + close(mkstemp(fnamebuf)); outfname = strsave(fnamebuf); } But I'm still wondering why you would use O_EXCL as a file descriptor on a new file that you're creating, unless you create and write in one operation. >From man (2) open O_EXCL error if create and file exists If O_EXCL is set with O_CREAT and the file already exists, open() returns an error. This may be used to imple- ment a simple exclusive access locking mechanism. If O_EXCL is set and the last component of the pathname is a symbolic link, open() will fail even if the symbolic link points to a non-existent name. That's fine if you only use it when you first create the file, but when you then try to open the file for writing later, this attribute causes the "File already exists" error, because the file really does exist. So you create a file that you can then not write to, which is what's happening here. Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/