Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 86F0C200C41 for ; Fri, 24 Mar 2017 21:28:38 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 85589160B93; Fri, 24 Mar 2017 20:28:38 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 53A7A160B75 for ; Fri, 24 Mar 2017 21:28:37 +0100 (CET) Received: (qmail 39762 invoked by uid 500); 24 Mar 2017 20:28:36 -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 39745 invoked by uid 99); 24 Mar 2017 20:28:34 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Mar 2017 20:28:34 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 51670C3A90 for ; Fri, 24 Mar 2017 20:28:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id lk5e4SpLW40t for ; Fri, 24 Mar 2017 20:28:32 +0000 (UTC) Received: from mx0b-00099f01.pphosted.com (mx0a-00099f01.pphosted.com [67.231.149.228]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id AF57A5FBB8 for ; Fri, 24 Mar 2017 20:28:31 +0000 (UTC) Received: from pps.filterd (m0074061.ppops.net [127.0.0.1]) by mx0a-00099f01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2OKLB8T026599 for ; Fri, 24 Mar 2017 15:28:22 -0500 Received: from crexpp03.us.aegon.com (email4.aegonusa.com [162.123.17.223]) by mx0a-00099f01.pphosted.com with ESMTP id 29ba127w14-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 24 Mar 2017 15:28:22 -0500 Received: from pps.filterd (crexpp03.us.aegon.com [127.0.0.1]) by crexpp03.us.aegon.com (8.16.0.17/8.16.0.17) with SMTP id v2OK4lfJ007867 for ; Fri, 24 Mar 2017 15:28:21 -0500 Received: from zix.inet.nogea.local (zix.inet.nogea.local [162.123.17.230]) by crexpp03.us.aegon.com with ESMTP id 29ba1ntfjr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 24 Mar 2017 15:28:21 -0500 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.aegonusa.com (Proprietary) with SMTP id 333911C189D for ; Fri, 24 Mar 2017 15:28:21 -0500 (CDT) Received: from crexppdlp01.us.aegon.com (unknown [162.123.252.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zix.inet.nogea.local (Proprietary) with ESMTPS id 912AB1C1507 for ; Fri, 24 Mar 2017 15:28:20 -0500 (CDT) Received: from pps.filterd (crexppdlp01.us.aegon.com [127.0.0.1]) by crexppdlp01.us.aegon.com (8.16.0.17/8.16.0.17) with SMTP id v2OKMT5Y017262 for ; Fri, 24 Mar 2017 15:28:14 -0500 Received: from crapdlp06.us.aegon.com (cremaildlp.us.aegon.com [162.123.194.16]) by crexppdlp01.us.aegon.com with ESMTP id 29b9uundh9-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 24 Mar 2017 15:28:14 -0500 Received: from transamerica.com (proofpointdlp.us.aegon.com [162.123.194.54]) by crapdlp06.us.aegon.com (8.13.8/8.13.8) with ESMTP id v2OKSDpG014364 for ; Fri, 24 Mar 2017 15:28:14 -0500 Received: from crexppdlp01.us.aegon.com (crexppdlp01.us.aegon.com [127.0.0.1]) by pps.mcdlp (8.16.0.16/8.16.0.16) with SMTP id v2OKMVBk017270 for ; Fri, 24 Mar 2017 15:28:13 -0500 Received: from crexmbx12.us.aegon.com (proofpointdlp.us.aegon.com [162.123.194.54]) by crexppdlp01.us.aegon.com with ESMTP id 29b9uundh8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 24 Mar 2017 15:28:13 -0500 Received: from crexmbx13.us.aegon.com (2002:a27b:d0c::a27b:d0c) by crexmbx12.us.aegon.com (2002:a27b:d0b::a27b:d0b) with Microsoft SMTP Server (TLS) id 15.1.466.34; Fri, 24 Mar 2017 15:28:13 -0500 Received: from crexmbx13.us.aegon.com ([fe80::109f:7395:bf:5534]) by crexmbx13.us.aegon.com ([fe80::109f:7395:bf:5534%19]) with mapi id 15.01.0466.034; Fri, 24 Mar 2017 15:28:13 -0500 From: "Bennett, Brian" To: "users@subversion.apache.org" Subject: Using svnperms.py and AuthzSVNAccessFile file together? Thread-Topic: Using svnperms.py and AuthzSVNAccessFile file together? Thread-Index: AdKk3ShM9W8aANknTICeqsWosPwnlA== Date: Fri, 24 Mar 2017 20:28:13 +0000 Message-ID: <09c69af944384fb6b6e14633121196c8@Transamerica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.123.144.130] x-exclaimer-md-config: 7562670a-beab-4c6e-8ed2-ab3b5287c042 Content-Type: multipart/alternative; boundary="_000_09c69af944384fb6b6e14633121196c8Transamericacom_" MIME-Version: 1.0 x-crexppdlp-TriggeredRule: module.access.rule.mcafee_dlp_reroute X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-24_19:,, signatures=0 X-RCIS-Action: ALLOW X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-24_19:,, signatures=0 X-VPM-MSG-ID: 826648c2-ce87-43d1-ade4-c3004be27e90 X-VPM-HOST: CREXZIX05.INET.NOGEA.LOCAL X-VPM-GROUP-ID: 7b0966a8-df85-4106-8487-ca585f29df2e X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-24_18:,, signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-24_19:,, signatures=0 archived-at: Fri, 24 Mar 2017 20:28:38 -0000 --_000_09c69af944384fb6b6e14633121196c8Transamericacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am able to use svnperms.py as written and have configured a working svnpe= rms.conf with it. My production Subversion environment is currently using a= n AuthzSVNAccessFile directive in the http configuration to specify groups = and read or read-write access; e.g.: [groups] grp1 =3D user1, user2, ... grp2 =3D user3, user4, ... [repo1:/] @grp1 =3D r @grp2 =3D rw . . . My question has to do with how it might be possible to "integrate" svnperms= .py usage alongside repositories that are using the permissions in the Auth= zSVNAccessFile file. I know that I can use the precommit hook to "engage" s= vnperms.py to give me the fine-grained read-write permissions that I am aft= er. But I'm struggling trying to figure out how to configure the two to wo= rk together. My goals are: * Have all read-write access controlled solely by svnperms.py * Restrict users that can read the repository I know that using "* =3D rw" in the AuthzSVNAccessFile file would allow all= read-write requests to be managed by svnperms.py, but it also allows all u= sers to have read access as well. So it is appearing like the only way to m= ake this work is to do something like the following in the AuthzSVNAccessFi= le file: [groups] readers1 =3D user1, user2 readers2 =3D user3, user4 writers =3D user5, user6, user7, user8 [repo1:/] @readers1 =3D r @writers =3D rw [repo1:/branches] @readers2 =3D r This would give @readers1 read access throughout the repository, @readers2 = read access to only the /branches and @writers read-write access to the ent= ire repository but have that access checked against svnperms.py via the pre= commit call. But it also forces me to list all possible read-write users in the AuthzSVN= AccessFile and again in my svnperms.conf file. Is there a configuration pos= sible where I don't have to list all possible read-write users in both the = AuthzSVNAccessFile and the svnperms.conf file? Brian Bennett | Supv System Admin & Support, TA TECH Change Mgmt/Production= Support o: 319-355-7602 | c: 319-533-1094 e: brian.bennett@transamerica.com | = w: www.transamerica.com Transamerica 6400 C St. SW, Cedar Rapids, IA 52404 MS-2410 Facebook | LinkedIn --_000_09c69af944384fb6b6e14633121196c8Transamericacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am able to use svnperms.py as written and have con= figured a working svnperms.conf with it. My production Subversion environme= nt is currently using an AuthzSVNAccessFile directive in the http configura= tion to specify groups and read or read-write access; e.g.:

 

[groups]

grp1 =3D user1, user2, …

grp2 =3D user3, user4, …

 

[repo1:/]

@grp1 =3D r

@grp2 =3D rw

.

.

.

 

My question has to do with how it might be possible = to “integrate” svnperms.py usage alongside repositories that ar= e using the permissions in the AuthzSVNAccessFile file. I know that I can u= se the precommit hook to “engage” svnperms.py to give me the fine-grained read-write permissions that I am after.  = But I’m struggling trying to figure out how to configure the two to w= ork together.

 

My goals are:

·         Have all read-write access controlled solely= by svnperms.py

·         Restrict users that can read the repository<= o:p>

 

I know that using “* =3D rw” in the Auth= zSVNAccessFile file would allow all read-write requests to be managed by sv= nperms.py, but it also allows all users to have read access as well. So it = is appearing like the only way to make this work is to do something like the following in the AuthzSVNAccessFile file:=

 

[groups]

readers1 =3D user1, user2

readers2 =3D user3, user4

writers =3D user5, user6, user7, user8

 

[repo1:/]

@readers1 =3D r

@writers =3D rw

[repo1:/branches]

@readers2 =3D r

 

This would give @readers1 read access throughout the= repository, @readers2 read access to only the /branches and @writers read-= write access to the entire repository but have that access checked against = svnperms.py via the precommit call.

 

But it also forces me to list all possible read-writ= e users in the AuthzSVNAccessFile and again in my svnperms.conf file. Is th= ere a configuration possible where I don’t have to list all possible = read-write users in both the AuthzSVNAccessFile and the svnperms.conf file?

 

Brian Bennett | Supv System Admin & Support, TA TECH Change Mgmt/Pr= oduction Support

o: 319-355-7602 | c: 319-533-1094

e: brian.bennett@transamerica.com | w: www.transamerica.com

Transamerica

6400 C St. SW, Cedar Rapids, IA= 52404 MS-2410

Facebook | LinkedIn<= /span>

 

--_000_09c69af944384fb6b6e14633121196c8Transamericacom_--