sharedRepository derived from file permissions

sharedRepository derived from file permissions

[Mark Hills]

We make extensive use of unix permissions and core.sharedRepository -- 
multiple developers push to the same repo.

I have often wondered why core.sharedRepository is needed at all as a 
separate configuration?

It looks like it might be easier (and less confusing to users) to derive 
this attribute from the top-level .git directory?

For many years in our organisation we have been using the scripts below to 
make it easier for users to configure a repository -- a one-time 
operation.

Is there a reason why Git doesn't just follow (and echo) the top-level 
permissions?

Many thanks

-- 
Mark


#!/bin/bash
#
# Propagate permissions of the top-level directory through a repository,
# and configure it for use.
#

if [ "$1" = "--help" ]; then
	echo "Usage: $0 <bare_git_repo>.git"
	echo "Fix permissions on a Git repository, based on the permissions"
	echo "at the top level directory."
	exit 0
fi

if [ -z "$1" ]; then
	echo "Repository argument is mandatory (see --help); aborting."
	exit 1
fi

REPO="$1"

if [ ! -d "$REPO/objects" -o ! -f "$REPO/config" -o ! -f "$REPO/HEAD" ]; then
	echo "$REPO does not look like a bare Git repository; aborting."
	exit 1
fi

# Fix ownership
chown -cR --reference="$REPO" "$REPO"/*

# Fix all the directory permissions after ownership (setting ownership
# removes setgid bit)
find "$REPO" -type d | xargs chmod -c --reference="$REPO"

# Fix files
find "$REPO" -type f | xargs chmod --reference="$REPO"
find "$REPO" -type f | xargs chmod a-sx

# Tidy up; permissions on object files are always 444
find "$REPO/objects" -type f | xargs chmod 0444

# Configure the repository to remove the need for further fixes
# by basing core.SharedRepository on the top level permissions
PERM=0`stat -c '%a' "$REPO"`
MODE=`printf %04o $(($PERM&0666))` # bash required
if [ "$MODE" = "0660" ]; then
	MODE=group
elif [ "$MODE" = "0666" ]; then
	MODE=all
fi
git --git-dir "$REPO" repo-config core.sharedRepository "$MODE"
chmod --reference="$REPO" "$REPO/config"
chmod a-sx "$REPO/config"

Re: sharedRepository derived from file permissions

[Junio C Hamano]

Mark Hills <mark@pogo.org.uk> writes:

> We make extensive use of unix permissions and core.sharedRepository -- 
> multiple developers push to the same repo.
>
> I have often wondered why core.sharedRepository is needed at all as a 
> separate configuration?
>
> It looks like it might be easier (and less confusing to users) to derive 
> this attribute from the top-level .git directory?

Hrm, clever ;-)

> Is there a reason why Git doesn't just follow (and echo) the top-level 
> permissions?

Other than "we did not trust that all the end users are capable of
doing the right 'chmod 2775 .git && chgrp project .git", with a
little bit of "we didn't think of that when we wrote the system", I
do not recall any.

Re: sharedRepository derived from file permissions

[Mark Hills]

On Mon, 8 Oct 2012, Junio C Hamano wrote:

> Mark Hills <mark@pogo.org.uk> writes:
> 
> > We make extensive use of unix permissions and core.sharedRepository -- 
> > multiple developers push to the same repo.
> >
> > I have often wondered why core.sharedRepository is needed at all as a 
> > separate configuration?
> >
> > It looks like it might be easier (and less confusing to users) to derive 
> > this attribute from the top-level .git directory?
> 
> Hrm, clever ;-)
> 
> > Is there a reason why Git doesn't just follow (and echo) the top-level 
> > permissions?
> 
> Other than "we did not trust that all the end users are capable of
> doing the right 'chmod 2775 .git && chgrp project .git", with a
> little bit of "we didn't think of that when we wrote the system", I
> do not recall any.

Thanks. If I understand, you mean it might be worth a try to implement 
this. For us it would certainly simplify, and reduce mistakes/confusion.

I've yet to look into the code, but I will try and do this. If you have 
any hints or recommendations where to begin then that'd be good.

I think I did peek some years ago to find out that it was non-trivial, and 
then came up with the script!

I wonder if there are any users who are granting permission to specific 
branchs or tags or tag directories. I'm not sure if this is really a valid 
use case, but there might need to be a way to ignore the top-level 
attributes too for some special cases?

Thanks

-- 
Mark

Re: sharedRepository derived from file permissions

[Junio C Hamano]

Mark Hills <mark@pogo.org.uk> writes:

>> > It looks like it might be easier (and less confusing to users) to derive 
>> > this attribute from the top-level .git directory?
>> 
>> Hrm, clever ;-)
>> 
>> > Is there a reason why Git doesn't just follow (and echo) the top-level 
>> > permissions?
>> 
>> Other than "we did not trust that all the end users are capable of
>> doing the right 'chmod 2775 .git && chgrp project .git", with a
>> little bit of "we didn't think of that when we wrote the system", I
>> do not recall any.
>
> Thanks. If I understand, you mean it might be worth a try to implement 
> this.

Not really.

I still do not think that all the end users are capable of doing the
right 'chmod 2775 .git && chgrp project .git' themselves.

Re: sharedRepository derived from file permissions

[Mark Hills]

On Wed, 17 Oct 2012, Junio C Hamano wrote:

> Mark Hills <mark@pogo.org.uk> writes:
> 
> >> > It looks like it might be easier (and less confusing to users) to derive 
> >> > this attribute from the top-level .git directory?
> >> 
> >> Hrm, clever ;-)
> >> 
> >> > Is there a reason why Git doesn't just follow (and echo) the top-level 
> >> > permissions?
> >> 
> >> Other than "we did not trust that all the end users are capable of
> >> doing the right 'chmod 2775 .git && chgrp project .git", with a
> >> little bit of "we didn't think of that when we wrote the system", I
> >> do not recall any.
> >
> > Thanks. If I understand, you mean it might be worth a try to implement 
> > this.
> 
> Not really.
> 
> I still do not think that all the end users are capable of doing the
> right 'chmod 2775 .git && chgrp project .git' themselves.

But with the current method, users still have to do this _and_ set 
sharedRepository=.

It would make things hard or impossible if we assume that a user wanting 
to share a repository does not understand file modes or groups.

-- 
Mark