From owner-freebsd-current@FreeBSD.ORG Sun Aug 15 20:59:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF7EE16A4CE; Sun, 15 Aug 2004 20:59:48 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC7743D39; Sun, 15 Aug 2004 20:59:48 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-67-115-74-195.dsl.lsan03.pacbell.net [67.115.74.195]) i7FKxhNW026906; Sun, 15 Aug 2004 16:59:43 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BEC255139B; Sun, 15 Aug 2004 13:59:46 -0700 (PDT) Date: Sun, 15 Aug 2004 13:59:46 -0700 From: Kris Kennaway To: Tim Kientzle Message-ID: <20040815205946.GA18580@xor.obsecurity.org> References: <20040813235434.GA75875@xor.obsecurity.org> <20040814063541.GA43063@xor.obsecurity.org> <411FCCCC.8040508@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <411FCCCC.8040508@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: Kris Kennaway Subject: Re: bsdtar's security restrictions (was Re: Spurious EACCES errors from apache) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2004 20:59:48 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 15, 2004 at 01:51:24PM -0700, Tim Kientzle wrote: > >With help from rwatson we tracked it down to bsdtar, which seems to be > >setting and resetting permissions on every path component when > >extracting a tarball.=20 >=20 > Yes, bsdtar does protect dirs that it is currently > extracting to in an attempt to close certain security > races. (Otherwise, there are windows during > the process of setting permissions, ownership, > ACLs, file flags, etc, when a file being > extracted may be vulnerable to another process.) >=20 > This is done for any directory explicitly mentioned > in the archive and any implicit directory that > is actually created. Directories that already > exist and are only referenced implicitly shouldn't > have their permissions edited. >=20 > > This is bad when some of those directories > >already exist, because other processes trying to access files in the > >directory hierarchy may lose the race and fail. >=20 > I don't think I understand what > exactly you're trying to do. >=20 > You are extracting archives over an existing directory > that is currently being served by an Apache process in > order to refresh some (presumably) small number of files? >=20 > Give me some more details about your situation and I'll > see what I can come up with. I pull in packages from package build clients with ssh client tar | tar. It creates archives like this: packages packages/All packages/All/uzap-1.0.tgz packages/editors packages/editors/uzap-1.0.tgz packages/Latest packages/Latest/uzap.tgz packages/ is supposed to have these permissions: drwxr-xr-x 93 ports-i386 portmgr 2048 Aug 14 23:12 packages/ But while the archive is being extracted it is changed to drwx------ 93 ports-i386 portmgr 2048 Aug 14 23:12 packages/ Thus, other processes that are concurrently trying to read other packages in that directory (apache, trying to serve them out as dependencies for other package builds) receive EACCESS. Kris --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBH87CWry0BWjoQKURAlOHAJoCzaKCYPJOhXlW5baFhEAWAbcXmACfdSWn NkpT25G56Y9MG5i3l+iLCvo= =80Ow -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--