public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
* Git destroys u+s and g+s directory modes
@ 2025-12-27  2:37 Hadmut Danisch
  2025-12-27 13:56 ` Michal Suchánek
  2026-01-02  7:55 ` Jeff King
  0 siblings, 2 replies; 9+ messages in thread
From: Hadmut Danisch @ 2025-12-27  2:37 UTC (permalink / raw)
  To: git

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27  2:37 Git destroys u+s and g+s directory modes Hadmut Danisch
@ 2025-12-27 13:56 ` Michal Suchánek
  2025-12-27 14:27   ` rsbecker
  2025-12-27 14:44   ` Hadmut Danisch
  2026-01-02  7:55 ` Jeff King
  1 sibling, 2 replies; 9+ messages in thread
From: Michal Suchánek @ 2025-12-27 13:56 UTC (permalink / raw)
  To: Hadmut Danisch; +Cc: git

On Sat, Dec 27, 2025 at 03:37:51AM +0100, Hadmut Danisch wrote:
> 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).

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Git destroys u+s and g+s directory modes
  2025-12-27 13:56 ` Michal Suchánek
@ 2025-12-27 14:27   ` rsbecker
  2025-12-27 14:40     ` Hadmut Danisch
  2025-12-27 14:44   ` Hadmut Danisch
  1 sibling, 1 reply; 9+ messages in thread
From: rsbecker @ 2025-12-27 14:27 UTC (permalink / raw)
  To: 'Michal Suchánek', 'Hadmut Danisch'; +Cc: git

On December 27, 2025 8:57 AM, Michal Suchánek wrote:
> On Sat, Dec 27, 2025 at 03:37:51AM +0100, Hadmut Danisch wrote:
> > 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).
> 
> 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.

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27 14:27   ` rsbecker
@ 2025-12-27 14:40     ` Hadmut Danisch
  2025-12-27 15:12       ` Andreas Schwab
                         ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Hadmut Danisch @ 2025-12-27 14:40 UTC (permalink / raw)
  To: rsbecker, 'Michal Suchánek'; +Cc: git


Am 27.12.25 um 15:27 schrieb rsbecker@nexbridge•com:
> 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.


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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27 13:56 ` Michal Suchánek
  2025-12-27 14:27   ` rsbecker
@ 2025-12-27 14:44   ` Hadmut Danisch
  1 sibling, 0 replies; 9+ messages in thread
From: Hadmut Danisch @ 2025-12-27 14:44 UTC (permalink / raw)
  To: Michal Suchánek; +Cc: git

On Sat, Dec 27, 2025 at 02:56:57PM +0100, Michal Suchánek 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.


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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27 14:40     ` Hadmut Danisch
@ 2025-12-27 15:12       ` Andreas Schwab
  2025-12-27 15:19       ` rsbecker
  2025-12-27 21:49       ` Gabor Gombas
  2 siblings, 0 replies; 9+ messages in thread
From: Andreas Schwab @ 2025-12-27 15:12 UTC (permalink / raw)
  To: Hadmut Danisch; +Cc: rsbecker, 'Michal Suchánek', git

On Dez 27 2025, Hadmut Danisch wrote:

> Am 27.12.25 um 15:27 schrieb rsbecker@nexbridge•com:
>> 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.
>
>
> This does not solve the problem, since ACLs do not propagate into newly
> created subdirectories, as group ownership with S_ISGID flag does.

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

-- 
Andreas Schwab, schwab@linux-m68k•org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: Git destroys u+s and g+s directory modes
  2025-12-27 14:40     ` Hadmut Danisch
  2025-12-27 15:12       ` Andreas Schwab
@ 2025-12-27 15:19       ` rsbecker
  2025-12-27 21:49       ` Gabor Gombas
  2 siblings, 0 replies; 9+ messages in thread
From: rsbecker @ 2025-12-27 15:19 UTC (permalink / raw)
  To: 'Hadmut Danisch', 'Michal Suchánek'; +Cc: git

On December 27, 2025 9:40 AM, Hadmut Danisch wrote:
> Am 27.12.25 um 15:27 schrieb rsbecker@nexbridge•com:
> > 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.
> 
> 
> 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.

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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27 14:40     ` Hadmut Danisch
  2025-12-27 15:12       ` Andreas Schwab
  2025-12-27 15:19       ` rsbecker
@ 2025-12-27 21:49       ` Gabor Gombas
  2 siblings, 0 replies; 9+ messages in thread
From: Gabor Gombas @ 2025-12-27 21:49 UTC (permalink / raw)
  To: Hadmut Danisch; +Cc: rsbecker, 'Michal Suchánek', git

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

> 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.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Git destroys u+s and g+s directory modes
  2025-12-27  2:37 Git destroys u+s and g+s directory modes Hadmut Danisch
  2025-12-27 13:56 ` Michal Suchánek
@ 2026-01-02  7:55 ` Jeff King
  1 sibling, 0 replies; 9+ messages in thread
From: Jeff King @ 2026-01-02  7:55 UTC (permalink / raw)
  To: Hadmut Danisch; +Cc: git

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

> 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.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2026-01-02  7:55 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-27  2:37 Git destroys u+s and g+s directory modes Hadmut Danisch
2025-12-27 13:56 ` Michal Suchánek
2025-12-27 14:27   ` rsbecker
2025-12-27 14:40     ` Hadmut Danisch
2025-12-27 15:12       ` Andreas Schwab
2025-12-27 15:19       ` rsbecker
2025-12-27 21:49       ` Gabor Gombas
2025-12-27 14:44   ` Hadmut Danisch
2026-01-02  7:55 ` Jeff King

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox