On Mon, May 18, 2015 at 11:58:03AM +0100, John McIntyre wrote: > 2015-05-18 11:26 GMT+01:00 Heiko Voigt <hvoigt@xxxxxxxxxx>: > > Hi, > > > > On Mon, May 18, 2015 at 11:07:02AM +0100, John McIntyre wrote: > >> Hi, > >> I've been asked to set up a git repository for a few projects. So I > >> have a Linux CentOS server running git. I place the repositories > >> under /opt and I use the .ssh/authorized_keys of the git user, to > >> grant access. The user sends me his private key, and I paste it into > >> the end of the file. > >> > >> And now, I realise that there's a problem. If I have /opt/repo1.git > >> and /opt/repo2.git, then all users can access both repositories. > >> > >> Is there a way to prevent this? > > > > If you want a simple tool using ssh-keys have a look at gitolite[1]. > > It quite simple to setup and with it you can specify all kinds of access > > rights. > > That's adding a separate level of complexity. Yes its a little more complex but not much. > I looked into filesystem-level permissions. I don't see any means of > doing so, because everyone accesses the repositories using the 'git' > user. So even if I add a group like 'devClient1' and then change the > group ownership of a repo to that user, they'll still be able to > access all repos..? No the repositories are only accessible by the defined groups/users. The access control is done by the gitolite layer. It uses the command option in the authorized_keys file to restrict access. The access rights and groups and so on are configured in its own gitolite.conf file which is itself stored in a git repository in which you commit and push to change them (or add more ssh-keys). It only uses ssh to authenticate the authorisation is then handled by the gitolite tool. In my experience this is a setup simpler to handle then groups and users directly on the server. It also allows to give a unique url for accessing one repository. With multiple system users you would have one url per user per repository which is not nice when sharing these and breaks (or needs extra complexity) when using submodules. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html