git gc changes ownerships of files linux

git gc changes ownerships of files linux

[K_V]

Hi team git

Running 'git -C /srv/mssioncontrol/.git gc' on linux from a user which
has access to another users files will occasionally change the
ownership of the file 'packed-refs'. I believe git actually overwrites
the file with a new one at the end af the gc command. But details
about this is not writen in the help text. Could it be a bug?

Use case: I'm using ansible to cleanup .git directories across
multible servers and this issue is starting to cause problems.

My solution is to make a variable containing the user and group id
before running gc command and then reapply it afterwards:
current_owner_uid_gid=$(stat -c "%u:%g" /srv/mssioncontrol/.git)
git -C /srv/mssioncontrol/.git gc
chown -R $current_owner_uid_gid "/srv/mssioncontrol/.git"

Details:
Debian GNU/Linux 12 (bookworm)
git version 2.39.2

Best:
zinen

Re: git gc changes ownerships of files linux

[Torsten Bögershausen]

On Sat, Feb 10, 2024 at 08:52:22PM +0100, K_V wrote:
> Hi team git
>
> Running 'git -C /srv/mssioncontrol/.git gc' on linux from a user which
> has access to another users files will occasionally change the
> ownership of the file 'packed-refs'. I believe git actually overwrites
> the file with a new one at the end af the gc command. But details
> about this is not writen in the help text. Could it be a bug?
>
> Use case: I'm using ansible to cleanup .git directories across
> multible servers and this issue is starting to cause problems.
>
> My solution is to make a variable containing the user and group id
> before running gc command and then reapply it afterwards:
> current_owner_uid_gid=$(stat -c "%u:%g" /srv/mssioncontrol/.git)
> git -C /srv/mssioncontrol/.git gc
> chown -R $current_owner_uid_gid "/srv/mssioncontrol/.git"
>
> Details:
> Debian GNU/Linux 12 (bookworm)
> git version 2.39.2

Thanks for reporting this -
I think that you have a working workaround ?

However, Git has a feature called "shared repository".
You need to define a (unix) group that is shared between
your user(s) and the ansible user.

The basic trick is to do
git config core.sharedRepository true

(And then change the ownership of all files/directories to the new group)

There is a docu here, please search for core.sharedRepository
https://git-scm.com/docs/git-config

I wonder, which solution is easier to maintain ?

>
> Best:
> zinen
>

Re: git gc changes ownerships of files linux

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On 2024-02-11 at 15:14:55, Torsten Bögershausen wrote:
> Thanks for reporting this -
> I think that you have a working workaround ?
> 
> However, Git has a feature called "shared repository".
> You need to define a (unix) group that is shared between
> your user(s) and the ansible user.
> 
> The basic trick is to do
> git config core.sharedRepository true
> 
> (And then change the ownership of all files/directories to the new group)

On Linux, you also should set each directory to be setgid.  That's
because by default, Linux uses the user's current group ID as the group
to create new directories.  However, you'll want the group to be
inherited from the parent directory, which is the behaviour when the
parent directory is setgid.

This behaviour is the default on the BSDs, and no such configuration is
required there.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: git gc changes ownerships of files linux

[Torsten Bögershausen]

On Sun, Feb 11, 2024 at 03:28:57PM +0000, brian m. carlson wrote:
> On 2024-02-11 at 15:14:55, Torsten Bögershausen wrote:
> > Thanks for reporting this -
> > I think that you have a working workaround ?
> >
> > However, Git has a feature called "shared repository".
> > You need to define a (unix) group that is shared between
> > your user(s) and the ansible user.
> >
> > The basic trick is to do
> > git config core.sharedRepository true
> >
> > (And then change the ownership of all files/directories to the new group)
>
> On Linux, you also should set each directory to be setgid.  That's
> because by default, Linux uses the user's current group ID as the group
> to create new directories.  However, you'll want the group to be
> inherited from the parent directory, which is the behaviour when the
> parent directory is setgid.
>
> This behaviour is the default on the BSDs, and no such configuration is
> required there.
Briam, Hm, I wonder what this function (in path.c) does:

int adjust_shared_perm(const char *path)

According to my understanding, it was included into the Git codebase
to work around the missing "setgid" feature in Linux (and probably cygwin).
And then we have t/t1301-shared-repo.sh,
so I think we are in a good shape: for all systems that have posix permissions.
and do not overwrite them with facl or other features.

Re: git gc changes ownerships of files linux

[Junio C Hamano]

Torsten Bögershausen <tboegi@web.de> writes:

> Briam, Hm, I wonder what this function (in path.c) does:
>
> int adjust_shared_perm(const char *path)
>
> According to my understanding, it was included into the Git codebase
> to work around the missing "setgid" feature in Linux (and probably cygwin).

No.  "g+s on directory" is required and depended upon for getting
the correct group ownership.  We do not do anything to chown(2) a
filesystem entry to force what group it is owned by there.

What adjust_shared_perm() does is to counter what the screwed-up
umask settings the user may have causes.  If you are a member of a
group and working in a directory owned by the group with other
members, you want to make sure others in the group can access the
files and the directories in the project.  Their umask should be
loosened to at least 027 and preferrably to 007 to give group
members the same access as you do.  Yet people do not loosen their
umask when starting work in such a group owned directory that is
supposed to be shared, as it would be extremely cumbersome to do
[*].  These users end up creating files with overly tight permission
bits, e.g. 0644 or 0700, and we go in with adjust_shared_perm() to
fix these modes.

You definitely must set up your initial directory with g+s if you
are usihng the group-writable shared directory model (which I would
actually be surprised to see in 2020---is a shared machine with more
than one user-account still a thing???); adjust_shared_perm() will
not help you there.


[Footnote]

* Unless, of course, you use some sort of "hook" in the shell to
  notice you switched to a certain directory and run command
  there---some people achieve this by aliasing their "cd", "pushd",
  and "popd".

Re: git gc changes ownerships of files linux

[Torsten Bögershausen]

On Sun, Feb 11, 2024 at 08:43:33AM -0800, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
> > Briam, Hm, I wonder what this function (in path.c) does:
> >
> > int adjust_shared_perm(const char *path)
> >
> > According to my understanding, it was included into the Git codebase
> > to work around the missing "setgid" feature in Linux (and probably cygwin).
>
> No.  "g+s on directory" is required and depended upon for getting
> the correct group ownership.  We do not do anything to chown(2) a
> filesystem entry to force what group it is owned by there.
>
> What adjust_shared_perm() does is to counter what the screwed-up
> umask settings the user may have causes.  If you are a member of a
> group and working in a directory owned by the group with other
> members, you want to make sure others in the group can access the
> files and the directories in the project.  Their umask should be
> loosened to at least 027 and preferrably to 007 to give group
> members the same access as you do.  Yet people do not loosen their
> umask when starting work in such a group owned directory that is
> supposed to be shared, as it would be extremely cumbersome to do
> [*].  These users end up creating files with overly tight permission
> bits, e.g. 0644 or 0700, and we go in with adjust_shared_perm() to
> fix these modes.
>
> You definitely must set up your initial directory with g+s if you
> are usihng the group-writable shared directory model (which I would
> actually be surprised to see in 2020---is a shared machine with more
> than one user-account still a thing???); adjust_shared_perm() will
> not help you there.
>

Oh - I learned something today and sorry for the noise.

>
> [Footnote]
>
> * Unless, of course, you use some sort of "hook" in the shell to
>   notice you switched to a certain directory and run command
>   there---some people achieve this by aliasing their "cd", "pushd",
>   and "popd".
>
>

Re: git gc changes ownerships of files linux

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

On 2024-02-11 at 16:43:33, Junio C Hamano wrote:
> You definitely must set up your initial directory with g+s if you
> are usihng the group-writable shared directory model (which I would
> actually be surprised to see in 2020---is a shared machine with more
> than one user-account still a thing???); adjust_shared_perm() will
> not help you there.

I think it's relatively common to have shell hosts from which to log
into production machines, or to have shared hosts for students at
universities, and I do know that shared web hosting is still quite
popular (because it tends to be very economical and low maintenance for
the user).

I don't know that shared repositories are really that common anymore,
and I do usually recommend that people clone their own copies whenever
possible, but I have seen posts on StackOverflow where people are in
fact using a shared repository (possibly with multiple worktrees) on one
system for various reasons.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

RE: git gc changes ownerships of files linux

[rsbecker]

On Sunday, February 11, 2024 2:10 PM, brian m. carlson wrote:
>On 2024-02-11 at 16:43:33, Junio C Hamano wrote:
>> You definitely must set up your initial directory with g+s if you are
>> usihng the group-writable shared directory model (which I would
>> actually be surprised to see in 2020---is a shared machine with more
>> than one user-account still a thing???); adjust_shared_perm() will not
>> help you there.
>
>I think it's relatively common to have shell hosts from which to log into production
>machines, or to have shared hosts for students at universities, and I do know that
>shared web hosting is still quite popular (because it tends to be very economical and
>low maintenance for the user).
>
>I don't know that shared repositories are really that common anymore, and I do
>usually recommend that people clone their own copies whenever possible, but I
>have seen posts on StackOverflow where people are in fact using a shared
>repository (possibly with multiple worktrees) on one system for various reasons.

In my community, shared repositories are particularly common on the operations side of the fence. It is a balance between the need for one user id (generally does not log on) running the scripts, and the individual operations staff specifying them. I have developed (commercial) solutions to this that remove the need shared repositories in this circumstance, but up to now, I have seen them used. This comes into play when multiple people are manipulating web server content without a separate deployment mechanism.