Petr Baudis [off-list ref] writes:
Rewrite refs in place in receive-pack & friends
When updating a ref, it would write a new file with the new ref and
then rename it, overwriting the original file. The problem is that
this destroys permissions and ownership of the original file, which is
troublesome especially in multiuser environment, like the one I live in.
Hmph. If a repo is _really_ used multiuser then you should not
have to care about ownership. If you can write into a
repository for a project (implying that you are a member of that
project group), and if your umask is set up correctly (meaning
it is 002 or looser), and with g+s bit on the directory at the
repository root level when it was created, shouldn't your newly
created ref file be also writable by others in that project?
On Sat, 13 Aug 2005, Junio C Hamano wrote:
Petr Baudis [off-list ref] writes:
quoted
Rewrite refs in place in receive-pack & friends
When updating a ref, it would write a new file with the new ref and
then rename it, overwriting the original file. The problem is that
this destroys permissions and ownership of the original file, which is
troublesome especially in multiuser environment, like the one I live in.
Hmph. If a repo is _really_ used multiuser then you should not
have to care about ownership.
I think Pasky's usage is that different heads are owned by different
groups and/or users, and he wants to use the filesystem permissions to
determine who gets to update which branch. Which is reasonable in a way.
On the other hand, I don't think filesystem permissions are really very
useful. I think it's more appropriate to use triggers to say something
like "only allow people in the 'xyz' group to write to this head".
Obviously, triggers aren't about _security_ - somebody who has write
permissions to the tree can always screw up others. But triggers are fine
for things like branch ownership, where you trust your users, but you just
want to avoid mistakes.
So a trigger might be something like
#!/bin/sh
. git-sh-setup-script
branch="$1"
old="$2"
new="$3"
if [ -e $GIT_DIR/permissions/$branch ]; then
id=$(id -un)
grep -q "^$id$" $GIT_DIR/permissions/$branch ||
die "You're not allowed to write to $branch"
fi
true
and that would allow you to list all users that are allowed to write to
the branch in $GIT_DIR/permissions/<branchname>.
Totally untested, of course. But the concept should work.
Linus
Dear diary, on Sun, Aug 14, 2005 at 02:55:16AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...
Petr Baudis [off-list ref] writes:
quoted
Rewrite refs in place in receive-pack & friends
When updating a ref, it would write a new file with the new ref and
then rename it, overwriting the original file. The problem is that
this destroys permissions and ownership of the original file, which is
troublesome especially in multiuser environment, like the one I live in.
Hmph. If a repo is _really_ used multiuser then you should not
have to care about ownership. If you can write into a
repository for a project (implying that you are a member of that
project group), and if your umask is set up correctly (meaning
it is 002 or looser), and with g+s bit on the directory at the
repository root level when it was created, shouldn't your newly
created ref file be also writable by others in that project?
Hmm, but how do you actually set the umask correctly just for git
pushing? I'm sorry but it doesn't occur to me.
I like Linus' solution, but have no time to do the patch now, so I did
just a quick dirty fix and added a chmod to hooks/update. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox