From: Junio C Hamano <gitster@pobox.com>
To: Jaime Frey <jfrey@cs.wisc.edu>
Cc: git@vger.kernel.org
Subject: Re: directory permissions on AFS
Date: Wed, 12 Dec 2012 16:17:28 -0800 [thread overview]
Message-ID: <7vd2ye24br.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <0A6FA42F-986D-4C3C-BC50-9A7C0494C703@cs.wisc.edu> (Jaime Frey's message of "Wed, 12 Dec 2012 17:39:30 -0600")
Jaime Frey <jfrey@cs.wisc.edu> writes:
> Stracing git revealed that it successfully recreated the ./objects/fb
> and then failed to chmod() it. It failed because it tried to set the
> S_ISGID bit, which mere mortals cannot do on AFS. Manually recreating
> all of these directories solves the problem.
We fix directory permissions after creating any directory under .git
with the same code, so that in a repository shared by group, new
subdirectories created by a random somebody who belongs to that
group will belong to that group (we also chmod to g+wx in case such
a random somebody has overly strict umask). Instead of running
chown(2) on every new file created by us, we let the filesystem to
take care of it by telling the directories we create that new files
in them should inherit their group ownership.
What we were worried about back when we decided to use S_ISGID was a
scenario like this:
* A repository is shared by group "src".
* A user belongs to the group "src". That group may or may not be
his primary group (i.e. "mkdir foo" done at random place by him
may not belong to the "src" group).
* The user attempts to create a new branch "foo/bar" by pushing
from outside. There is no other branch whose name is
"foo/anything" when this happens.
* An equivalent of "mkdir -p .git/refs/heads/foo" needs to be done
before an equivalent of "echo $sha >.git/refs/heads/foo/bar"
happens to accept this push. We want "foo" and "bar" to belong
to "src" group and they get appropriate permission bits suitable
to be accessed by the members of the "src" group.
The story is the same for loose objects and their fan-out directory.
Storing a commit object fb/012345... may need to create the leading
fan-out ".git/objects/fb" and we want that directory and any future
files created in it to belong to the "src" group.
Any alternative implementation that achieves the same result that
works on AFS can be substituted with the current code, or made
conditionally activated on AFS.
prev parent reply other threads:[~2012-12-13 0:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 23:39 directory permissions on AFS Jaime Frey
2012-12-13 0:17 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vd2ye24br.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jfrey@cs.wisc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox