From: Andreas Ericsson <ae@op5.se>
To: Andre Masella <andre@masella.no-ip.org>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: Repository Security
Date: Wed, 24 Jan 2007 10:31:32 +0100 [thread overview]
Message-ID: <45B72774.1070508@op5.se> (raw)
In-Reply-To: <200701230823.20061.andre@masella.no-ip.org>
Andre Masella wrote:
>>> As I understand it, none of the repository backends allow any per-user
>>> per-branch access control. SSH and HTTP come the closest with the right
>>> hooks, but since the repository is writeable by those users, there is
>>> little to stop them from changing the repository directly.
>> I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV access)
>> just to rely on filesystem write access to refs/heads files (different
>> files having different access rights), and filesystem ACLs.
>
> It could probably be done, but it would be very complicated. For instance, if
> a user is allowed to run prune, then they must have permissions to delete
> files which would include any of the objects.
>
Pruning is considered a "repository admin task". Since each git developer has
a full copy of the entire project locally, they can prune their local repo
as much as they like without it affecting the mothership repo.
Pruning of the mothership repo should be done by whoever administers the host
where it is hosted, and probably not even by him/her unless diskspace becomes
an issue.
We have 42 mothership repos at our workplace. Combined in those repos we've got
2962 dangling objects. Pruning them would save me 8.5MiB of diskspace. It's
hardly worth even thinking about.
> For DAV, this breaks down completely because all access to the repository will
> happen as the Apache user.
Indeed. We use real system accounts for pushing/pulling. It's convenient for
those of us who use ssh-agent, and functional for those who don't. It also
allows "fine-grained-enough" access control to the repos.
Normally we have all repos owned by <project-leader>:devel and created with
umask 002. All developers are in the "devel" group and can thus by default
push and fetch from all repositories. Some repos require stricter access
rights. For those we create a group specially.
The "everyone can read" thingie isn't necessary, but it's nice because it
lets our head of development take a look at whatever he wants without us
running any risk of him damaging it (he's a suit after all).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2007-01-24 9:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-22 19:33 Repository Security Andre Masella
2007-01-22 20:53 ` Shawn O. Pearce
2007-01-23 13:23 ` Andre Masella
2007-01-22 23:46 ` Martin Langhoff
2007-01-23 9:41 ` Johannes Schindelin
2007-01-23 13:23 ` Andre Masella
2007-01-23 14:29 ` Johannes Schindelin
2007-01-23 15:00 ` Andy Parkins
2007-01-23 11:06 ` Jakub Narebski
2007-01-23 13:23 ` Andre Masella
2007-01-23 21:38 ` Johannes Schindelin
2007-01-24 9:31 ` Andreas Ericsson [this message]
2007-01-23 16:18 ` Linus Torvalds
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=45B72774.1070508@op5.se \
--to=ae@op5.se \
--cc=andre@masella.no-ip.org \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/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).