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