Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 31859187BE for ; Sat, 1 Aug 2015 07:44:29 +0000 (UTC) Received: (qmail 7020 invoked by uid 500); 1 Aug 2015 07:44:24 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 6963 invoked by uid 500); 1 Aug 2015 07:44:24 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 6953 invoked by uid 99); 1 Aug 2015 07:44:23 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Aug 2015 07:44:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 349C8C0617 for ; Sat, 1 Aug 2015 07:44:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=wandisco.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id YEbXTcfrY4Lr for ; Sat, 1 Aug 2015 07:44:16 +0000 (UTC) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 852A7205B8 for ; Sat, 1 Aug 2015 07:44:15 +0000 (UTC) Received: by wibud3 with SMTP id ud3so56433942wib.0 for ; Sat, 01 Aug 2015 00:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XjC6t0XZ+slVyDoRqlKCv4tELOZumy5AIQScVy0qncM=; b=k3eISqmjO5/UW/glerzJgghazjIiF/Q4CnkDsv8G9eJWBmYnWXiJWXE1OIoZper2Iy afmNBkjZ9T8EakJ5xi/EmwGX4E07K6pFb6fyNYJACImacOZfK7y8n3MENq2TPTU8Udp0 Zj1OSzpanstzOSn3/Q4qABvvsCS8Y+s5lmMsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XjC6t0XZ+slVyDoRqlKCv4tELOZumy5AIQScVy0qncM=; b=HgS0EquCpQOrUaz1+5/RBo6VJgx3e2NJAk7NPLYaYKZGNIEMzoDKz2arIJFRD8Kxxe +dU6346DKqc6qcN8Gu5k6C3Z+KhBW6Ni4C7Ug3wIiwWte00qNZJ2/G6sIbEVcrNsK3NW BgP2uwtquRVs17YzdlITKtWCDWg49uKpUT27HWt8Hi+Ars3RBx3kNH3Lal3x3wjbrhGc 4+/lmv5SkI5Qp1NAqFHknWja01suqsdnLroa54YPa8YlpckuSgAQxKlpKBbHeVbuJihx 8QbzjikFar8gzg5YVhL3PXqhVH65bkPu4p5Epsl7J+Xvaq+c6KQ5Pti9JVox27GTvUVg M7Mw== X-Gm-Message-State: ALoCoQmykisc94/2ULCt9w3ifKMVD/8d00le8FMNt1IHqtiD5NFcp6NO1BBlcr2Zk+K+y4tt1ked X-Received: by 10.180.88.196 with SMTP id bi4mr15517269wib.70.1438415008734; Sat, 01 Aug 2015 00:43:28 -0700 (PDT) Received: from zulu.23.e-reka.si (cpe-46-164-5-176.dynamic.amis.net. [46.164.5.176]) by smtp.gmail.com with ESMTPSA id pg9sm11098160wjb.40.2015.08.01.00.43.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 01 Aug 2015 00:43:27 -0700 (PDT) Received: from zulu.23.e-reka.si (localhost [127.0.0.1]) by zulu.23.e-reka.si (Postfix) with ESMTP id D18D3F45452E for ; Sat, 1 Aug 2015 09:43:25 +0200 (CEST) Message-ID: <55BC789D.40001@wandisco.com> Date: Sat, 01 Aug 2015 09:43:25 +0200 From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= Organization: WANdisco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dev@subversion.apache.org Subject: Re: The patch-exec branch References: <20150726120157.0D7D7AC0024@hades.apache.org> <20150726120759.GC6221@tarsus.local2> <55B501D3.4050708@wandisco.com> <20150731233636.GD2054@tarsus.local2> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 01.08.2015 09:24, Greg Stein wrote: > On Fri, Jul 31, 2015 at 6:36 PM, Daniel Shahaf > wrote: > >... > > Two questions: > > - When one side of the diff is in the OS filesystem, do we still fold > its value to 644/755 for output? > > - If yes, how do we choose between 644 and 755? (e.g., do we use > "x & 0111 == 0111", or "x & 0100 == 0100", or access(X_OK), or …) > > My answer to the first question is "yes", as discussed above. > > > Whatever the answer, I don't think the client should _ever_ set > group/world *write* [directed by the "server"]. Maybe not execute, > too. That just screams for creating a point of abuse. (maybe umask > applies, but I'd prefer to ignore that; we're getting perm bits from > (potentially) an untrusted server) We have io_set_file_perms in libsvn_subr/io.c which we should be using here. Currently it tries to set all executable bits (user, group and world) but only the user-write bit for readonly/writable transitions. I don't recall offhand if apr_file_perms_set filters by umask or not. And FWIW, we should ignore the read-write perms from Git diffs and only (try to) tweak the executable bit. Having a read-only versioned file in our working copy that doesn't also have the svn:needs-lock property will likely cause all sorts of problems. -- Brane