From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R9scG-00076U-2j for garchives@archives.gentoo.org; Sat, 01 Oct 2011 06:00:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 840BE21C08B; Sat, 1 Oct 2011 05:59:52 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 2A31621C070 for ; Sat, 1 Oct 2011 05:58:47 +0000 (UTC) Received: from mail-bw0-f53.google.com ([209.85.214.53]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1R9sb1-002rS0-BC for gentoo-user@lists.gentoo.org; Sat, 01 Oct 2011 12:58:47 +0700 Received: by bkbzt12 with SMTP id zt12so3228530bkb.40 for ; Fri, 30 Sep 2011 22:58:42 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.223.17.219 with SMTP id t27mr8791216faa.123.1317448722266; Fri, 30 Sep 2011 22:58:42 -0700 (PDT) Received: by 10.223.74.196 with HTTP; Fri, 30 Sep 2011 22:58:42 -0700 (PDT) Received: by 10.223.74.196 with HTTP; Fri, 30 Sep 2011 22:58:42 -0700 (PDT) Date: Sat, 1 Oct 2011 12:58:42 +0700 Message-ID: Subject: Re: [gentoo-user] {OT} Development framework with access restriction? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=001517440f6619bb5904ae366f8e X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: X-Archives-Hash: 8126f0000fb83a182139ebf8d37ac1df --001517440f6619bb5904ae366f8e Content-Type: text/plain; charset=UTF-8 On Oct 1, 2011 7:26 AM, "Michael Orlitzky" wrote: > > On 09/30/2011 07:59 PM, Grant wrote: > > > > Thanks for that. I haven't thought it all the way through, but if > > Unix ownership and permissions aren't granular enough and subversion's > > path-based authorization won't work, I will need to use ACLs. I think > > both subversion's path-based authorization and Unix > > ownership/permissions would be simpler to implement and maintain than > > ACLs so I'm hoping it doesn't come to that. > > > > ACLs really aren't as bad as they look at first. They work just like > permissions on Windows, which are one of the few things it does right. > My example is made much more difficult because /var/www contains > directories writable by other customers. > > I know *my* config.php files are chgrp apache and chmod 660, but I don't > expect everyone else to be so careful (and they shouldn't have to be). > > If you are going to go the version control route, I would suggest > setting up a new repository with only the code that he will be working > on. You can use a post-update script (or whatever svn calls them) on the > server to pull his code into production. He doesn't need to access the > files directly. > +1 on production server pulling from $VCS. I'm currently assisting a friend of mine, who's the CEO of a business incubator. In order to force them startups to use the $VCS, we require them to first commit their codes to the $VCS, then have a script pull the newest version into production. At first, they whined. Oh, how they whined! But after the $VCS saved their bacons many times, now they're firm believers in version control :-) Rgds, --001517440f6619bb5904ae366f8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Oct 1, 2011 7:26 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 09/30/2011 07:59 PM, Grant wrote:
> >
> > Thanks for that. =C2=A0I haven't thought it all the way throu= gh, but if
> > Unix ownership and permissions aren't granular enough and sub= version's
> > path-based authorization won't work, I will need to use ACLs.= =C2=A0I think
> > both subversion's path-based authorization and Unix
> > ownership/permissions would be simpler to implement and maintain = than
> > ACLs so I'm hoping it doesn't come to that.
> >
>
> ACLs really aren't as bad as they look at first. They work just li= ke
> permissions on Windows, which are one of the few things it does right.=
> My example is made much more difficult because /var/www contains
> directories writable by other customers.
>
> I know *my* config.php files are chgrp apache and chmod 660, but I don= 't
> expect everyone else to be so careful (and they shouldn't have to = be).
>
> If you are going to go the version control route, I would suggest
> setting up a new repository with only the code that he will be working=
> on. You can use a post-update script (or whatever svn calls them) on t= he
> server to pull his code into production. He doesn't need to access= the
> files directly.
>

+1 on production server pulling from $VCS.

I'm currently assisting a friend of mine, who's the CEO of a bus= iness incubator. In order to force them startups to use the $VCS, we requir= e them to first commit their codes to the $VCS, then have a script pull the= newest version into production.

At first, they whined. Oh, how they whined! But after the $VCS saved the= ir bacons many times, now they're firm believers in version control :-)=

Rgds,

--001517440f6619bb5904ae366f8e--