13

Every time I do git pull or git reset, git resets changes to permissions and ownership I made. See for yourself:

#!/usr/bin/env bash rm -rf 1 2 mkdir 1 cd 1 git init echo 1 > 1 && git add 1 && git ci -m 1 git clone . ../2 cd $_ chmod 0640 1 chgrp http 1 cd ../1 echo 12 > 1 && git ci -am 2 cd ../2 stat 1 git pull stat 1

The output:

$ ./1.sh 2>/dev/null | grep -F 'Access: (' Access: (0640/-rw-r-----) Uid: ( 1000/ yuri) Gid: ( 33/ http) Access: (0664/-rw-rw-r--) Uid: ( 1000/ yuri) Gid: ( 1000/ yuri)

Is there a way to work around it?

I want to make some files/directories accessible for writing by the web server.

Improve this question

2 Answers 2

Reset to default
5

This sounds like the user you're running has the default group set to yuri. You can confirm this like so:

$ id -a uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel),989(wireshark)

The UID of your account is this: uid=1000(saml) whereas the default group is git=1000(saml) and any secondary groups are thereafter.

NOTE: If you want the git clone to have specific ownership, then you have at least 2 options.

Option #1

Set a parent directory with the permissions as you want like so:

$ mkdir topdir $ chgrp http topdir $ chmod g+s topdir $ cd topdir $ git clone ....

This forced the directory topdir to enforce any child directories underneath it to have the group http applied. This will work by in large but can lead to problems, since if you move files into this git clone workspace, those files will not have their groups enforced by the changes made above.

Option #2

Prior to doing work, change your default group to http like so:

$ newgrp http $ git clone ...

This method will force any new files created to have their group set to http instead of your normal default group of yuri, but this will only work so long as you remember to do a newgrp prior to working in this workspace.

Other options

If neither of these seem acceptable you can try using ACLs instead on the git workspace directory. These are discussed in multiple Q&A's on this site, such as in this Q&A titled: Getting new files to inherit group permissions on Linux.

Improve this answer
6
  • First, you must be meaning newgrp. Then, does it change group for current shell only? And lastly, the point was to make only specific files/directories accessible for writing by web server. After all, I should probably fix them manually, or set up some git hook... Commented Oct 11, 2014 at 9:14
  • 1
    @x-yuri - yes sorry it's 5am here and I'm about to go to bed 8-). Yes this only persists for the current shell, so that would be a downside to that approach. If you're intending for only certain access for the webserver then that's going to be tricky, and you'll likely want to use ACLs then. Also you might want to add these details to your Q. As it is, it's unclear what your intended purpose is, so I can only answer you in non-specific terms. Commented Oct 11, 2014 at 9:16
  • 1
    @x-yuri - a post update hook like this may be more apt: stackoverflow.com/questions/9613545/… Commented Oct 11, 2014 at 9:22
  • 1
    @x-yuri - controlling permissions is discussed in the git book under hooks: git-scm.com/book/en/Customizing-Git-Git-Hooks Commented Oct 11, 2014 at 9:24
  • I don't actually see how changing group for only current shell may be a downside, to be honest. I was concerned about it not changing the way the rest of apps work. Commented Oct 11, 2014 at 10:05
2

The solution I use is to run the command as the user that has the permissions you want to keep:

sudo -u user command

This keeps the permissions from changing. I use it when updating git repositories on my VPS, while keeping the file permissions set to the webserver user.

See also the same question here.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.