search

charmbracelet / git-lfs-transfer

Server-side implementation of the Git LFS pure-SSH protocol
MIT License
52 stars 6 forks source link

core.sharedrepository=1 causes invalid permissions in generated files #46

Open JD06450 opened 4 months ago

JD06450 commented 4 months ago

Describe the bug In the setPermissions function in cmd_unix.go, it mistakes the value of '1' as being an octal file mode instead of it's intended value of true. This causes the backend struct to have a umask of 776 and as a result all files pushed to the server via LFS will end up with an object file with the permissions 001 / --------x.

Setup Please complete the following information along with version numbers, if applicable.

Note: you might encounter rendering issues if your locale does not use UTF-8 encoding. Please check your locale (locale on POSIX systems) to see what encoding is being used by your system.

To Reproduce Steps to reproduce the behavior:

  1. Make a shared git repo using the command git init --bare --shared. (You can manually check the git config for the repo to ensure that core.sharedrepository=1. It may not be for you, but it did for me, which triggered the bug.)
  2. Initialize git-lfs using git lfs install
  3. Add git-lfs-transfer to the PATH
  4. Clone the repo somewhere else using ssh git clone ssh://server:/path/to/myrepo.git
  5. Add a file to the repo and tell git-lfs to track it.
  6. Commit the file and push to the server.

Expected behavior Since I used the --shared flag when creating the repo, and in cmd_unix.go the switch statement on the shared repository option includes an option for "true" which acts the same as "group", I would expect the permissions to be set to 660 which would mean the umask would be 117.