core.sharedrepository=1 causes invalid permissions in generated files

[JD06450]

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.

• OS [Ubuntu 22.04 LTS]
• Shell [bash]

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.