My concern with commit-only permission restrictions are that I would need 
to allow the ability for everyone who can push to directly edit 
/etc/files/environments/{production,development}/*, 
which could break a lot of things in this environment.  

What are your thoughts on adding the sticky bit to 
/etc/files/environments/{production,development} 
and allowing the end users rwx permission to those folders.  Since our 
/etc/files/environments/{production,development}* 
environment is chowned to a service account, this will stop them from doing 
anything like rm -rf /etc/files/environments/{production,development} 
(which would destroy all of the top-level files in those directories, 
regardless of the user permissions on the files themselves).  

However, I'm wondering if I need to do any sort of chowning in a pre-commit 
hook to the user for things like 
/etc/files/environments/{production,development}/index.  

Thoughts?  


On Friday, October 24, 2014 3:41:25 AM UTC-4, Magnus Therning wrote:
>
> On Thu, Oct 23, 2014 at 12:30:09PM -0700, Jon Zeolla wrote: 
> > Hi Konstantin, 
> > 
> > I apologize - it appears that all of the objects in this directory 
> > are owned by the individual who pushes them, but it seemed like an 
> > anomaly because my file permissions script overwrote all of the 
> > older file permissions with a service account.   
> > 
> > I agree, something like gitolite right now would be overkill if I 
> > could avoid it.  Is there a way to move where index.lock is created? 
> > Then I would be less worried and could give them rwx permissions to 
> > that folder, which has nothing important underneath it.   
>
> Sure, it may be overkill if you look at the feature list; you only 
> need a small subset of features offered by gitolite.  But looking at 
> the effort you spend it may well be the easiest way forward. 
>
> AFAIU you are trying to limit access to specific "areas" of you git 
> repo using file permissions.  I'd say that's not a solution to the 
> permission problem that is particularly common and thus unlikely to 
> well supported.  I believe the most common way to introduce 
> permissions inside a git repo is through using hooks, which AFAIU is 
> exactly how gitolite does it. 
>
> I've seen there are collections of hooks out there (e.g. 
> <https://github.com/icefox/git-hooks>), maybe that's another way 
> forward if you don't want to go down the set-up-a-git-server route. 
>
> You may also be interested in this [SO post on gitosis vs 
> gitolite](http://stackoverflow.com/a/10888536/34996). 
>
> /M 
>
> -- 
> Magnus Therning                      OpenPGP: 0xAB4DFBA4 
> email: mag...@therning.org <javascript:>   jabber: mag...@therning.org 
> <javascript:> 
> twitter: magthe               http://therning.org/magnus 
>
> Code as if whoever maintains your program is a violent psychopath who 
> knows 
> where you live. 
>      -- Anonymous 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to