All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gonzalo Garramuño" <ggarra@advancedsl.com.ar>
To: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: Git and securing a repository
Date: Thu, 03 Jan 2008 02:36:25 -0300	[thread overview]
Message-ID: <477C7459.3020402@advancedsl.com.ar> (raw)
In-Reply-To: <20080103035838.GA24004@spearce.org>

Shawn O. Pearce wrote:
> 
> If you read the documentation carefully you will note that the
> pre-receive hook receives input on stdin; 1 line of data per ref
> that is being pushed with the old/new SHA-1 values and the ref
> name.  The hook exits 0 to allow all changes to take place and
> can exit > 0 to abort and disallow all updates.
> 

Sure, but I cannot pass any sort of authentication to the script other 
than rely on environment variables or system calls, as git will not 
provide anything else.

To do proper authentication on a file or directory basis, I have to mix 
two things then:

A user/group base authentication/login based likely on unix permissions 
and ssh AND a pre-receive hook script that finds the user/group name and 
then checks whether the user can change that particular file/directory.

I hope the ref name is the (relative) path name to the file and not just 
the file's basename.

If so, I can see that most of what I want to do is possible.  It is just 
pretty far from being elegant or easy to set up.

To distinguish a bad commit due to tabs for example from an actual 
permission trouble.  I'm assuming that the stderr/stdout of git hooks is 
redirected back to the client?

Even with all of that, it seems it is still not possible to limit pulls 
to a certain directory only, right?

Anyway, I think I more or less have the answer I (sadly) expected. 
Git's authorization mechanism is pretty much a roll your own type thing. 
  I'll check out the python authorization script that Linus mentioned to 
see if that alleviates setup troubles a bit.

-- 
Gonzalo Garramuño
ggarra@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy

  parent reply	other threads:[~2008-01-03  4:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-02  7:13 Git and securing a repository Gonzalo Garramuño
2008-01-02  6:34 ` Felipe Balbi
2008-01-02 10:04   ` Gonzalo Garramuño
2008-01-02  9:26     ` David Symonds
2008-01-02 10:39       ` Gonzalo Garramuño
2008-01-02 10:51         ` Jakub Narebski
2008-01-03  3:58           ` Shawn O. Pearce
2008-01-03  4:30             ` Bruno Cesar Ribas
2008-01-03  5:36             ` Gonzalo Garramuño [this message]
2008-01-03  4:45               ` Shawn O. Pearce
2008-01-03  6:08                 ` Gonzalo Garramuño
2008-01-03  5:19                   ` Shawn O. Pearce
2008-01-03  9:11             ` Jakub Narebski
2008-01-03  9:36               ` Junio C Hamano
2008-01-02 19:31     ` Jan Hudec
2008-01-02 19:41       ` Gregory Jefferis
2008-01-02 22:17     ` Linus Torvalds
2008-01-02 16:18 ` Daniel Barkalow

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=477C7459.3020402@advancedsl.com.ar \
    --to=ggarra@advancedsl.com.ar \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.