From: Carl Baldwin <cnb@fc.hp.com>
To: git@vger.kernel.org
Subject: [RFC] Using sticky directories to control access to branches.
Date: Thu, 17 Nov 2005 10:01:29 -0700 [thread overview]
Message-ID: <20051117170129.GA14013@hpsvcnb.fc.hp.com> (raw)
I had a thought this morning. I wanted to use file permissions to
control access to push to a particular branch in a repository in order
to implement some sort of per-branch policy. This assumes that there is
a repository setup into which multiple users can push.
My goals were to be able to...
a) allow only one user (or possibly one group) access to modify a
branch. Do this on per-branch basis.
b) Freeze tags so that they *cannot* be accidentally updated by a push.
My plan to accomplish this was to set the sticky bit (chmod +t) on the
refs/heads and refs/tags directories so that users couldn't bypass
file-permissions by replacing the file with their own. Then grant write
permission to the owner (or possibly a group) to allow updates to that
branch.
I started testing this with git v0.99.9i and found that git push
actually creates a new file and replaces the old branch file with the
new one. The consequence for me is that when I set the sticky bit on
the heads directory then all of the branches restrict access solely to
the owner of the file since only the owner will be able to replace it.
This precludes giving a group write access to the branch. It also
precludes leaving most of the branches open to all users by default.
Now, git was probably designed to do this on purpose because it is the
safest way to update a branch in an automic way. But, I wonder if there
is another way. Maybe, git could make a temporary backup of the branch
doing something like this:
% cp refs/heads/master{,.$randomstring}
(on success, go ahead and edit refs/heads/master in place)
(on success, remove refs/heads/master.$randomstring
Something like this could still be pretty safe but would allow
per-branch access restrictions using unix file permissions.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
next reply other threads:[~2005-11-17 17:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 17:01 Carl Baldwin [this message]
2005-11-18 7:55 ` [RFC] Using sticky directories to control access to branches Junio C Hamano
2005-11-21 18:01 ` Carl Baldwin
2005-11-21 19:29 ` Junio C Hamano
2005-12-01 15:42 ` Carl Baldwin
2005-12-02 1:13 ` Junio C Hamano
2005-12-02 9:29 ` Andreas Ericsson
2005-12-02 9:35 ` Junio C Hamano
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=20051117170129.GA14013@hpsvcnb.fc.hp.com \
--to=cnb@fc.hp.com \
--cc=git@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).