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
From: Michal Suchánek <hidden> Date: 2025-12-27 13:57:04
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
On December 27, 2025 8:57 AM, Michal Suchánek wrote:
On Sat, Dec 27, 2025 at 03:37:51AM +0100, Hadmut Danisch wrote:
quoted
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
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
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
On December 27, 2025 9:40 AM, Hadmut Danisch wrote:
Am 27.12.25 um 15:27 schrieb rsbecker@nexbridge.com:
quoted
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.
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
From: Jeff King <hidden> Date: 2026-01-02 07:55:29
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