From users-return-9650-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Sun Jul 3 00:05:05 2011 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9DFF667B4 for ; Sun, 3 Jul 2011 00:05:05 +0000 (UTC) Received: (qmail 74105 invoked by uid 500); 3 Jul 2011 00:05:05 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 74072 invoked by uid 500); 3 Jul 2011 00:05:04 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 74063 invoked by uid 99); 3 Jul 2011 00:05:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Jul 2011 00:05:04 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nkadel@gmail.com designates 209.85.210.43 as permitted sender) Received: from [209.85.210.43] (HELO mail-pz0-f43.google.com) (209.85.210.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Jul 2011 00:04:59 +0000 Received: by pzk1 with SMTP id 1so5390675pzk.16 for ; Sat, 02 Jul 2011 17:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vYJrN7mT4Zs5Mi4gpsr+BJz8nfEFG2B9DW6initEsIQ=; b=b2TTrVamkKpNVTcbIL0RCWx9h3bse2jAZ3/jPR3XuyrSQmTRtaQ+Ahb7MMJyVn+zDQ 2wq5pD6U/5vHijeVL9J924MYoW4cMFmmr/gkoFLGOM6ZlWCoHrWf977EPWJfUmt3M6Zr 2DPvNWmQweUvmEv9d4Rh8oK8Vc9/JMOrcyng4= MIME-Version: 1.0 Received: by 10.68.50.9 with SMTP id y9mr6036189pbn.24.1309651478611; Sat, 02 Jul 2011 17:04:38 -0700 (PDT) Received: by 10.68.65.198 with HTTP; Sat, 2 Jul 2011 17:04:38 -0700 (PDT) In-Reply-To: <20110702211719.GA2731@daniel3.local> References: <4E0DA839.5090405@gmail.com> <9B21F0BBE52BF74DBA71AB889C021DD705AF8434@exisland01.omnifone.com> <4E0DB338.8060402@gmail.com> <9B21F0BBE52BF74DBA71AB889C021DD705AF84BE@exisland01.omnifone.com> <4E0DCEE4.2050103@gmail.com> <20110702211719.GA2731@daniel3.local> Date: Sat, 2 Jul 2011 20:04:38 -0400 Message-ID: Subject: Re: Branching Questions From: Nico Kadel-Garcia To: Daniel Shahaf Cc: Geoff Hoffman , Andy Levy , Phil Pinkerton , Tony Sweeney , Subversion User List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 2, 2011 at 5:17 PM, Daniel Shahaf wrot= e: > Could you please be more precise? =A0svn+ssh:// is completely fine (if yo= u > configure authorized_keys(5) correctly), it's admins who give their > users filesystem write access to the repository directory who are the > problem. I consider svn+ssh the closest thing to remotely securable access for Subversion. I didn't mean to deprecate it in any way. I may have misunderstood the phrase "possibly some Apache configuration tweaks" to mean doing path based control on the Apache server side. This is surprisingly common: I've been forced to use it several times for employers. The problem is that if it's done purely in the Apache configuration, that access control will have no affect on file:// or svn+ssh:// based access, and this is actually what the "Subversion Red Book" describes. svnserve path based access control, which is what svn+ssh uses, is entirely distinct from Apache access control in the examples. I've not personally used both at the same time because the security model winds up very confused. Getting Subversion services under "suexec" doesn't work, and putting in authorized_keys for the apache daemon owner gets....... crazy making. So you wind up doing things like common group ownership and sgid directory settings, which are *not* propagated by svnadmin hotcopy. So running both access methods at the same time, with anything other than read-only public access for the Apache service, gets nutty.