Basically I followed the steps described here to convert my existing git repository to one shared (writable) with a particular group. But one thing I forget to do is:

git config core.sharedRepository group

The "sharedRepositoy" config was originally not existed in "core". After another group member X commit his changes, I can no longer push my changes. More worse, in the .git/objects/ directory I saw the owner of some directories changed to user X instead of me; the group ID remain unchanged but the group permission becomes "r-s" instead of the expected original "rws". Therefore I can no longer do "chmod" or "chown" to those directories.

Question #1: Why is this happening? I mean, what exactly are the user settings to make the group permission of those directories change from "rws" to "r-s"? Or is it simply because I didn't enable "sharedRepository" in the config?

Question #2: Is it possible to fix it myself without asking user X or system admin to fix it? I don't belong to sudoers but I am still a member of that group, with the "setgid" flag set, is there a way to use this to regain my control back?

Thanks!

CodePudding user response：

(This question, and my answer here, probably belongs on Superuser or Unix&Linux.)

Why is this happening? I mean, what exactly are the user settings to make the group permission of those directories change from "rws" to "r-s"? Or is it simply because I didn't enable "sharedRepository" in the config?

It's the lack of the shared-repository setting, yes:

• Git creates new directories to hold files, now and then.

• Git creates new files, now and then.

• Whenever Git makes these, it uses mkdir or open, and sets the Unix-level mode to 0777 (directory) or 0666 (file), but the OS then clears certain bits according to the current process's umask, which is normally 022.

• Setting the shared-repository setting tells Git to call umask(002) early on, so that only one bit is cleared, instead of two. The result is that directories are created as rwxrwxr-x and files are created as rw-rw-r--. (The s you see (rws or r-s) is a separate bit, the setgid bit, that the OS provides on its own based on the containing directory. The setgid bit causes the new file or directory's group ownership to be that of the containing directory; by propagating this bit into newly-created directories, newly-created files within those directories retain this feature.)

Is it possible to fix it myself without asking user X or system admin to fix it?

Possibly. It's probably wiser to have an admin do it.

I don't belong to sudoers but I am still a member of that group, with the "setgid" flag set, is there a way to use this to regain my control back?

Because you're in the correct group, you can, yourself, create your own directories. You can set your own umask to 002 and make a directory:

umask 002; mkdir tmp

and then you can copy files within some incorrectly-permitted directory into the new one, then swap the names around:

cp 02/* tmp && mv 02 02-bad && mv tmp 02

for instance. However, doing this atomically is not possible: these steps take time and someone else can run a Git command while that's going on. If that happens, the copies may be inconsistent. It's far simpler and less error-prone for some administrator to chmod g w any directories and files for which this is required. (If your chmod has it, chmod -R g=u gitdir is probably correct sufficient, though I have not tested it.)