Re: [git-users] Git objects and user permissions
From: Jon Zeolla zeo...@gmail.com Nevermind I guess the sticky bit trickles down throughout the whole directory structure. Strictly speaking, the default value of the sticky bit when a directory is created is the sticky bit value of its parent directory. It trickles down when the directories are created. Dale -- 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.
Re: [git-users] Git objects and user permissions
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.
Re: [git-users] Git objects and user permissions
On Wed, 22 Oct 2014 09:23:18 -0700 (PDT) Jon Zeolla zeo...@gmail.com wrote: 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? May be try running git repack -a -d to get those objects stuffed into a pack file? 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. Yes, that post has hit my inbox as well as I'm able to see it via the Google's web interface to this list. I was about asking why not using, say, gitolite with its virtual refs mechanism allowing you to specify fine-grained rules for who can change which paths but from that your first post it appears, you're using several repos on the same filesystem so going through gitolite would probably be an overkill. -- 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
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.
