Git destroys u+s and g+s directory modes

Hi,

(please respond to my e-mail as well, not just to the list, I'm not subscribed),

I do have a problem with git 2.43.0 (ubuntu server 24.04.3) and directory modes:

I do need my git repo (owned by me) to be readable by a system user (running a rootless podman container).

I therefore set a special group for the directory, and set the sgid bit of the directory ( chgrp ... and chmod 2770 ), but when doing a git clone onto that directory, git rewrites all file modes, including the one of the root directory, and the  S_ISGID is lost.

The only setting I found about file modes is core.fileMode, but git docs tell that this is for file systems that do not keep permissions correctly, such as CIFS or Windows bases file systems, not for keeping git from changing.

The only way I found is to define a hook to correctly set modes after git pull.

Is there a way to keep git from destroying group permission and S_ISGID?

If not: Proposal to set a bit mask with file mode flags git shouldn't touch?

regards

Hadmut

On Sat, Dec 27, 2025 at 03:37:51AM +0100, Hadmut Danisch wrote:

When you want it to be readable you do not need any special permission bits.

You can set the directories and files to be readable by group, and ensure the container user is part of the group.

You are porbably looking for core.sharedRepository configuration option.

If git is particularly unhappy accessing a readonly repository and the container is short-lived you can add an overlay over the repository when creating the container.

HTH

Michal

On December 27, 2025 8:57 AM, Michal Suchánek wrote:

bits.

the

container is

There is an option with ubuntu: Access Control Lists (ACLs). These provide override security for directories that might assist in your process without having to worry about git security settings. It might be worth looking into this option.

Randall

Am 27.12.25 um 15:27 schrieb rsbecker@nexbridge.com:

This does not solve the problem, since ACLs do not propagate into newly created subdirectories, as group ownership with S_ISGID flag does.

Please try to understand the problem before trying to solve it.

regards

Hadmut

On December 27, 2025 9:40 AM, Hadmut Danisch wrote:

Without trying to be critical, the POSIX ACLs I have seen provide an option that provides inheritance, so nothing in the repository will block those. That is why I mentioned it. However, perhaps ubuntu does not support that capability.

On Dez 27 2025, Hadmut Danisch wrote:

You can set the default ACL on a directory, which is then inherited by all newly created files.

On Sat, Dec 27, 2025 at 03:40:11PM +0100, Hadmut Danisch wrote:

Well, default ACLs may very well be the solution to your problem, because git does not understand ACLs, so it would leave them alone. Of coure, managing ACLs at scale have their fair share of problems, so YMMV. The problem with the permission bits is git trying to be clever and thinking it can manage them - but as often, trying to be clever ends up not being clever at all. Unfortunately, there does not seem to be a configuration option to tell git to leave permission bits alone. core.filemode is the closest one, but what you want is the opposite behavior - what you want is not ignoring the executable bit, but ignoring everything _except_ the executable bit. Maybe you can try to make a patch...

Regards, Gabor

On Sat, Dec 27, 2025 at 02:56:57PM +0100, Michal Suchánek wrote:

And that's the problem: 

"ensure the container user is part of the group" is what the S_ISGID flag on directories is good for: It ensures that newly created directories inherit their parent's group. Unix administration basics. 

And this is the bit git clears and breaks this mechanism. 

regards

Hadmut

On Sat, Dec 27, 2025 at 03:37:51AM +0100, Hadmut Danisch wrote:

Can you show more exactly what commands you're running? From your description, it sounds like this:

  mkdir clone

  # just a convenient group that I happen to be in but which is not the
  # default
  chgrp audio clone
  chmod 2770 clone

  ls -ld clone
  git clone $SOME_URL clone
  ls -ld clone clone/* clone/*/* clone/.git

Before the clone, I have:

  drwxrws--- 2 peff audio 4096 Jan  2 02:53 clone

and after:

  drwxrws--- 4 peff audio 4096 Jan  2 02:53 clone
  drwxrwsr-x 8 peff audio 4096 Jan  2 02:53 clone/.git
  drwxrwsr-x 2 peff audio 4096 Jan  2 02:53 clone/sub
  -rw-rw-r-- 1 peff audio    8 Jan  2 02:53 clone/sub/file

So the sgid bits were preserved and propagated to subdirectories, and everything was added to the correct group. Do you get different results? Or does my recipe not match what you're trying to do?

-Peff