I've been using git for some time and love it. For open source projects
there's clearly nothing currently better.
However, I am now using git for proprietary elements, which in the
future I may need or want to partially restrict access to. The idea
being that at my company some (junior) developers should not be given
access to some elements. That means either that some full git
repository should be password protected or even portions of the same
repository.
Another desirable way to protect elements might be only giving
clone/pull access to a repository (or portion of it) but not permissions
to push in changes.
I have not seen or read much about how git deals with accesses and
permissions. Can anyone point me to some documentation if some or all
of this is possible?
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
From: Felipe Balbi <hidden> Date: 2016-06-15 22:44:02
On Jan 2, 2008 2:13 AM, Gonzalo Garramuño [off-list ref] wrote:
I've been using git for some time and love it. For open source projects
there's clearly nothing currently better.
However, I am now using git for proprietary elements, which in the
future I may need or want to partially restrict access to. The idea
being that at my company some (junior) developers should not be given
access to some elements. That means either that some full git
repository should be password protected or even portions of the same
repository.
Another desirable way to protect elements might be only giving
clone/pull access to a repository (or portion of it) but not permissions
to push in changes.
push access is only available through ssh, so if your developer
doesn't have a ssh account on the server, he can't push code to it
I have not seen or read much about how git deals with accesses and
permissions. Can anyone point me to some documentation if some or all
of this is possible?
it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.
If a user is not the owner nor is part of that group in particular, it
wouldn't be able to push any code to the repository.
btw, if you don't start git-daemon you could use ssh to pull code as well.
thinking on the partial repository access, maybe git submodule would
help, but i've never used it.
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.
Thanks. I'll admit what you describe is somewhat discouraging, as what
you are just describing is just managing user accounts or groups on the
underlying OS. That does not extend well to placing code on the net and
has a bunch of administrative headaches.
I was really looking for a permission based system that was part of git
itself (and thus more portable and easier to admin), and not the OS.
Something akin to what perforce or even CVS can do.
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
From: David Symonds <hidden> Date: 2016-06-15 22:44:02
On Jan 2, 2008 9:04 PM, Gonzalo Garramuño [off-list ref] wrote:
Felipe Balbi wrote:
quoted
it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.
Thanks. I'll admit what you describe is somewhat discouraging, as what
you are just describing is just managing user accounts or groups on the
underlying OS. That does not extend well to placing code on the net and
has a bunch of administrative headaches.
I was really looking for a permission based system that was part of git
itself (and thus more portable and easier to admin), and not the OS.
Something akin to what perforce or even CVS can do.
You can do arbitrarily-fine-grained authentication via the pre-receive hook.
Dave.
You can do arbitrarily-fine-grained authentication via the pre-receive hook.
Can you provide some more info? Looking at the kernel.org git docs, the
pre-receive hook seems very limited as no parameters are allowed. So
I'm not sure how an authentication system could be created.
It also seems to be a push hook only (not invoked on pulls).
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:02
Gonzalo Garramuño [off-list ref] writes:
David Symonds wrote:
quoted
You can do arbitrarily-fine-grained authentication via the
pre-receive hook.
Can you provide some more info? Looking at the kernel.org git docs,
the pre-receive hook seems very limited as no parameters are allowed.
So I'm not sure how an authentication system could be created.
It also seems to be a push hook only (not invoked on pulls).
Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).
There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.
AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:44:02
On Wed, 2 Jan 2008, Gonzalo Garramuño wrote:
I've been using git for some time and love it. For open source projects
there's clearly nothing currently better.
However, I am now using git for proprietary elements, which in the future I
may need or want to partially restrict access to. The idea being that at my
company some (junior) developers should not be given access to some elements.
That means either that some full git repository should be password protected
or even portions of the same repository.
Another desirable way to protect elements might be only giving clone/pull
access to a repository (or portion of it) but not permissions to push in
changes.
In order to understand the security model, you have to remember that git
is designed as a distributed system. Authorization is fundamentally not at
a project level, but rather at a repository level, and clones are all
different repositories. This makes portability of the mechanism less
important, because a particular set of authorization rules only applies to
a particular repository, which is going to be on some single system.
For that matter, git doesn't run with any special privileges in general;
if a user can affect the repository with git operations, that user can
affect the repository by hand, so git-specific rules aren't helpful.
(Although I suppose it would be theoretically useful to make git-shell,
the shell that only runs git programs, able to apply restrictions, since
it is used in a context where the user doesn't have any other access to
the filesystem.)
For read access restrictions, you want to use submodules (or entirely
separate projects); git is fundamentally unhappy running with less than
all of the project accessible, except for when a project references
another project with submodules. And, of course, if the code base is such
that users can do useful work without any access to some of the files,
those files must be optional and somewhat separate from the necessary
portions, and it makes sense to handle them separately anyway.
-Daniel
*This .sig left intentionally blank*
From: Jan Hudec <hidden> Date: 2016-06-15 22:44:02
On Wed, Jan 02, 2008 at 07:04:09 -0300, Gonzalo Garramuño wrote:
Felipe Balbi wrote:
quoted
it's easy on the full repository case, create different groups and
share git repositories by groups, after that chmod o-rwx -R
/path/to/repository.git.
Thanks. I'll admit what you describe is somewhat discouraging, as what you
are just describing is just managing user accounts or groups on the
underlying OS. That does not extend well to placing code on the net and
has a bunch of administrative headaches.
I was really looking for a permission based system that was part of git
itself (and thus more portable and easier to admin), and not the OS.
Something akin to what perforce or even CVS can do.
You don't need to manage user accounts -- managing ssh public keys will do!
The git ssh access will always run one particular command (with path as
argument) to push and another particular command (again with path as
argument) to pull.
Thus you can prepare two scripts -- git-read-only will only run
$SSH_ORIGINAL_COMMAND if it is 'git-upload-pack <somearg>' and git-read-write
will also run it if it is 'git-receive-pack <somearg>'. The <somearg> is path
to the repository, so you can further limit on that. (Note: for recent git,
you need to recognize the 'git upload-pack' and 'git receive-pack' variants
too).
Now you can have each user create a ssh public key. You will put this key
into the .ssh/authorized_keys file on the server (therefore you only need
a single account there), with option command= specifying appropriate script
depending on what permissions the user should have. Than that user will be
able to push/pull (as set) via ssh using that public key and will not have
any other access to the server.
As a bonus, this way the users can't circumvent the pre-receive hooks
(perhaps you will allow each user to only push to a particular branch or
something) by manually changing the repository.
--
Jan 'Bulb' Hudec [off-list ref]
I was really looking for a permission based system that was part of git itself
(and thus more portable and easier to admin), and not the OS. Something akin
to what perforce or even CVS can do.
Well, git by design doesn't do that.
That doesn't mean that it has to be OS-level permissions (in fact, it
generally shouldn't), it just means that git wasn't really meant to care
about permissions itself, and you the user management and permissions
should come from "outside".
That outside *can* be OS-level things like just permissions on files, but
more commonly it's things like SSH keys and using the git hooks. In other
words, pretty much by design, git is meant to be the *core* SCM
infrastructure, and then you layer your user management on top of it as a
*separate* layer.
An example of that would probably be gitosis, but I haven't used it
myself. For the kernel, people literally tend to just use SSH accounts,
and not any central repository at all (ie the kind of crazy "central repo
access control rules" that centralized repos need are just not necessary
at all in a more distributed usage model).
See
http://eagain.net/gitweb/?p=gitosis.githttp://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
for a quick starting point on gitosis, if that suits your needs (there's
more, google is your friend).
Linus
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:02
Jakub Narebski [off-list ref] wrote:
Gonzalo Garramuño [off-list ref] writes:
quoted
David Symonds wrote:
quoted
You can do arbitrarily-fine-grained authentication via the
pre-receive hook.
Can you provide some more info? Looking at the kernel.org git docs,
the pre-receive hook seems very limited as no parameters are allowed.
So I'm not sure how an authentication system could be created.
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.
This is a "batch" form of the update hook.
quoted
It also seems to be a push hook only (not invoked on pulls).
Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).
Authentication could be supported for http, ftp, or ssh based fetch,
but there you are relying on the server that provides access to do
the authentication and authorization for you; typically that will
boil down to UNIX filesystem read permission. Though with HTTP
and a fancy Apache config it doesn't have to be.
There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.
update-paranoid uses the update hook rather than pre-receive to
allow it to allow/deny on a per-ref basis. One of the flaws of
the pre-receive hook "API" is it is an all-or-nothing proposition.
So by using the "older" update hook update-paranoid can make its
decision on a per-ref basis and allow some refs to change in this
push but abort/deny others. I find that useful but not everyone
might.
AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.
No, they are *not* invoked on fetch. Currently no hooks execute
during fetch; either on the server *or* on the client side of
the connection.
--
Shawn.
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:02
Gonzalo Garramuo [off-list ref] wrote:
Shawn O. Pearce wrote:
quoted
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.
Correct.
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.
No, the ref name is the name of the branch being modified. If there
is only one branch in your repository its probably always going to
be the default name of "refs/heads/master".
If you want to know what files the user has changed you need to
diff the two SHA-1s (old against new) to come up with the names of
the files being changed; e.g.:
git diff-tree -r $old $new
The update-paranoid hook in contrib has support for doing this
built-in and can allow A/M/D type changes on specific file paths,
entire directories, or any regex pattern that matches the above.
I use this at day-job to prevent users from doing stupid things to
directories they shouldn't be changing on particular branches.
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?
You need to diff the old against the new (or use rev-list to list
all of the commits between old and new and then get the patch for
each of those commits) to determine if the commit is "bad" or not.
Remember that a single git-push can upload hundreds of commits in
one shot to the receiving repository.
But yes, both stdout and stderr of the hook are tied to the stderr
of the client running git-push. So error messages produced by
the hook to explain why the push is being denied are visible to
the end-user who is executing git-push. Again, update-paranoid
uses this to tell you if the "committer" line in commit objects is
invalid, or if you are changing a file you shouldn't be.
Even with all of that, it seems it is still not possible to limit pulls
to a certain directory only, right?
No. Git pretty much requires that when you have access to fetch/pull
a repository you have access to *all* of that repository. Limiting to
a subdirectory would actually require moving that entire subdirectory
into its own repository and using git-submodule instead to manage it.
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.
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.
As such it also usually boils down to UNIX filesystem security; what
I let you see is what you can see, what I firewall and hide from
you is what you cannot see. Quite simple when you think about it,
but then you are moving away from a centralized development model
and going to a distributed one... which is what Git was built for.
--
Shawn.
From: Bruno Cesar Ribas <hidden> Date: 2016-06-15 22:44:02
I lost ohter mails, so replying here =)
I wrote sometime ago i wrote[1] a bunch of BASH scripts to manage SSH_ACL and "internal"
plugin is to manage GIT repositories.
It is simple and you can grant access to a user for R or W. And there is NO
need to create more users just a "git" user is nice.
I'm re-writing it to become more flexible about configuration and to add more
plugins.
We are using it at C3SL[2] to manage our projects and Write permissions are
set because we don't want some developers pushing to anothers projects.
bruno
[1]http://www.inf.ufpr.br/ribas/ssh_acl/
[2]http://www.c3sl.ufpr.br
On Wed, Jan 02, 2008 at 10:58:38PM -0500, Shawn O. Pearce wrote:
Jakub Narebski [off-list ref] wrote:
quoted
Gonzalo Garramuño [off-list ref] writes:
quoted
David Symonds wrote:
quoted
You can do arbitrarily-fine-grained authentication via the
pre-receive hook.
Can you provide some more info? Looking at the kernel.org git docs,
the pre-receive hook seems very limited as no parameters are allowed.
So I'm not sure how an authentication system could be created.
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.
This is a "batch" form of the update hook.
quoted
quoted
It also seems to be a push hook only (not invoked on pulls).
Some of read-only (fetch only) access protocols do not support
authentication: http, ftp, rsync, git. Authentication is provided only
for access via ssh and for push via https (WebDAV).
Authentication could be supported for http, ftp, or ssh based fetch,
but there you are relying on the server that provides access to do
the authentication and authorization for you; typically that will
boil down to UNIX filesystem read permission. Though with HTTP
and a fancy Apache config it doesn't have to be.
quoted
There is example update hook in contrib/hooks, named update-paranoid,
which could be base of what you want. Note that you probably rather
use newer pre-receive hook instead of older update hook.
update-paranoid uses the update hook rather than pre-receive to
allow it to allow/deny on a per-ref basis. One of the flaws of
the pre-receive hook "API" is it is an all-or-nothing proposition.
So by using the "older" update hook update-paranoid can make its
decision on a per-ref basis and allow some refs to change in this
push but abort/deny others. I find that useful but not everyone
might.
quoted
AFAIK both update and pre-receive hooks are invoked also on fetch...
but I might be mistaken.
No, they are *not* invoked on fetch. Currently no hooks execute
during fetch; either on the server *or* on the client side of
the connection.
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
--
Gonzalo Garramuño
ggarra@advancedsl.com.ar
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:02
Gonzalo Garramuo [off-list ref] wrote:
Shawn O. Pearce wrote:
quoted
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.