Re: [git-users] Git objects and user permissions

2014-10-24 Thread Jon Zeolla
Nevermind I guess the sticky bit trickles down throughout the whole 
directory structure.  

On Friday, October 24, 2014 2:31:15 PM UTC-4, Jon Zeolla wrote:

 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   jabber: mag...@therning.org 
 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.


[git-users] Git objects and user permissions

2014-10-22 Thread Jon Zeolla
Hi,

I have some pretty stringent permissions in git (via posix extended file 
attributes), as we attempt to delegate access to pushing certain directory 
structures to certain groups of individuals within our team.  

We had an issue the other day where a user tried to push (git push live) 
but didn't have enough permission to create the index.lock file.  The user 
did have write permission to the objects and refs directories.  The git 
logs (git log -p) show that the push had been successful, but there are 
files hanging around in the objects directory from this user.  Typically 
the only files that are in the objects directory are from the last user 
that pushed, but at this point there has been at least one successful push 
since this failed attempt to push but the objects from two pushes back 
still remain here.  

I'm just not sure if these should be here or not...  Or how to clear them 
out.  I did verify that they are valid, and the files that were attempted 
to be pushed via git cat-file -p hash.  Any ideas?  


I also wrote a very detailed question yesterday about this but I do not see 
it here or in my activity log, so I'm not sure what happened...  But if 
that happens to pop up at some point, I apologize for the double post.  


Jon

-- 
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.