git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: "Gonzalo Garramuño" <ggarra@advancedsl.com.ar>
Cc: git@vger.kernel.org
Subject: Re: Git and securing a repository
Date: Thu, 3 Jan 2008 00:19:31 -0500	[thread overview]
Message-ID: <20080103051931.GC24004@spearce.org> (raw)
In-Reply-To: <477C7BF8.2090406@advancedsl.com.ar>

Gonzalo Garramuo <ggarra@advancedsl.com.ar> wrote:
> Shawn O. Pearce wrote:
> >
> >Its a distributed version control system.  All peers are equal.
> >Most security in Git is handled by only pulling from sources you
> >trust, and never allowing someone to push stuff into a repository
> >you own.
> >
> 
> Regarding that... is there a way to control the umask of a git clone 
> independent of the actual umask of the user or directories inside the 
> repository?  Ideally, on the server side?
> 
> That is, for sensitive repositories, I would like "git clone" to always 
> clone that repository with 0700 permissions, so that the silly mistake 
> of cloning a sensitive repository into a public directory and forgetting 
> to restrict its permissions can be avoided completely.

No.

For a local clone (same UNIX system) you could probably easily
modify git-clone.sh to consult the config file of the source
repository to obtain recommended initial permissions, or just use
the source repository's directory permissions as the new clone's
initial permissions.  But not everyone would want that behavior.

For a remote clone (different systems) the config file of the source
repository isn't easily available.  So its not easily used to get
that setting.  The git protocol would have to be extended to make
transfer of parts of the config file possible.  We've talked about
this in the past but have never had a compelling application to
cause patches to be submitted for it.

-- 
Shawn.

  reply	other threads:[~2008-01-03  5:20 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
2008-01-03  4:45               ` Shawn O. Pearce
2008-01-03  6:08                 ` Gonzalo Garramuño
2008-01-03  5:19                   ` Shawn O. Pearce [this message]
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=20080103051931.GC24004@spearce.org \
    --to=spearce@spearce.org \
    --cc=ggarra@advancedsl.com.ar \
    --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).