git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

             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).