Git远程推送权限异常求助：objects目录权限不一致排查

Let's break down your problem step by step and outline actionable troubleshooting directions to get all users creating objects subdirectories with the correct rwxrwsr-x permissions.

Key Background #

First, a quick recap to align: Git relies on the parent objects directory's setgid (g+s) bit to ensure new subdirectories inherit the repository's shared group, and the core.sharedRepository config to enforce consistent permissions across users. Your issues stem from inconsistent group permissions on subdirectories and unexpected behavior despite a global umask 0022.

Troubleshooting Directions #

1. Verify the Top-Level objects Directory's Permissions & Group

The root of permission inheritance issues almost always starts here. Log into your SLES server, navigate to the bare repo, and run:

ls -ld objects

• You should see drwxrwsr-x (setgid bit enabled) and the group should be a shared group that all Git users belong to (e.g., git-users).
  • If the group is a user-specific private group, other users won't inherit the correct group when creating subdirectories.
  • If the setgid bit is missing, new subdirectories won't inherit the parent group at all.

2. Confirm All Users Belong to the Shared Git Group

Check that every user (both those who can push and those who can't) is part of the same shared group:

id <username>

Look for the shared group (e.g., git-users) in the groups output. If a user isn't in the group:

• Add them with:

  usermod -aG git-users <username>
  

• Have the user log out and back in to apply the group change.

3. Check the Repository's core.sharedRepository Config

Git has a built-in setting to manage shared repository permissions. Run this in the bare repo:

git config core.sharedRepository

• If it returns nothing or false, Git isn't enforcing shared permissions. Set it to group to tell Git to ensure group read/write access and preserve the setgid bit:

  git config core.sharedRepository group
  

• After setting this, fix existing problematic objects subdirectories:

  chgrp -R git-users objects  # Replace with your shared group
  chmod -R g+ws objects       # Add group write and setgid to all subdirs
  

4. Validate Users' Actual Umask (Not Just the Default)

You mentioned a global umask 0022, but individual users might override this in their shell configs. Ask affected users to run:

umask

• umask 0022 creates directories with rwxr-xr-x (755) by default. Combined with a setgid parent directory, this would result in rwxr-sr-x (no group write)—exactly your problematic permission.
• Users who can create rwxrwsr-x likely have a umask 0002 (creates rwxrwxr-x/775 directories), which when combined with setgid becomes the correct rwxrwsr-x.

To fix this:

• Add umask 0002 to a global shell config (e.g., /etc/profile or /etc/bash.bashrc) to enforce it for all users.
• Check individual users' ~/.bashrc, ~/.profile, or ~/.zshrc (if using zsh) to remove any local umask overrides.

5. Check Filesystem Mount Options

Rarely, filesystem mount settings can interfere with setgid inheritance. Run mount and look at the partition hosting your Git repos. Ensure there are no nosuid, nodev, or restrictive gid options that block group permission inheritance. If ACLs are enabled, verify they aren't overriding standard Unix permissions.

6. Check User Shell Environments

Some users might be using a different shell (e.g., sh instead of bash) that doesn't load the global umask config. Ask affected users to run echo $SHELL and confirm their shell loads the global profile files.

Why Are Some Users Creating Correct Permissions? #

The most likely reasons are:

• Those users have a umask 0002 (either via local config or accidental override) that creates directories with group write access.
• They were the ones who initialized the repository, so Git automatically set the correct setgid and group permissions on the top-level objects directory, and their subdirectories inherited those settings correctly.
• Their shell environment correctly applies the shared group as their primary/effective group when interacting with the repo.

Final Fix Steps Recap #

1. Create and assign all Git users to a shared group (e.g., git-users).
2. Set core.sharedRepository = group in every bare repo.
3. Fix existing objects directory permissions and group ownership.
4. Enforce umask 0002 globally for all users.
5. Verify the top-level objects directory has the setgid bit enabled and belongs to the shared group.

内容的提问来源于stack exchange，提问作者Andreas Zimmermann