Is there a way how to prevent users, who I would like to be able to add repositories and modify permissions, from changing permissions of gitolite-admin?
The gitolite-admin repo is usually only RW by the gitolite admin account.
repo gitolite-admin
RW+ = gitoliteadm
Ie it isn't visible by any other users.
So they won't be able to clone that repo, and access the gitolite.conf file which would allow them to change permission on any repo.
Repos creation
Now, with Gitolite V3, you can authorize users to declare new repo and create them without giving them access to the gitolite-adm repo.
This is called "wild repo".
The wildrepos feature allows you to specify access control rules using regular expression patterns, so you can have many actual repos being served by a single set of rules in the config file.
The regex pattern can also include the word CREATOR in it, allowing you to parametrize the name of the user creating the repo.
#prof = u1
#TAs = u2 u3
#students = u4 u5 u6
repo assignments/CREATOR/a[0-9][0-9]
C = #students
RW+ = CREATOR
RW = WRITERS #TAs
R = READERS #prof
Note the "C" permission.
This is a standalone "C", which gives the named users the right to create a repo.
This is not to be confused with the "RWC" or its variants described elsewhere, which are about branches, not repos.
Permission management
It is called delegation:
Delegation allows you to divide up a large conf file into smaller groups of repos (called subconfs) and hand over responsibility to manage them to sub-admins.
Gitolite can prevent one sub-admin from being able to set access rules for any other sub-admin's repos.
Related
We desire to make subversion repositories read only. Doing this for a single repository in a subversion instance did not work regarding ssh. ssh access appears to bypass the controls of svn.
Followed the suggestions here:
Read-only access of Subversion repository
Write access should be restricted but that did not happen.
The repository is still write accessible despite changes to the repository for read only.
The easiest way to restrict access (assuming there are no users who require write access) is to remove the w (write) bit on the files in the SVN repo.
chmod -R gou-w /path/to/svn-repo
That will prevent writes at the filesystem / OS level.
If some users still require access, you can create separate svn+ssh endpoints for each user class that map to different users on the host server, using group write vs other write bits to determine which group has access to affect writes:
mkgrp writers-grp
chgrp -R writers-grp /path/to/svn-repo
chmod ug+w /path/to/svn-repo
chmod o-w /path/to/svn-repo
I would then register the SSH keys for writers against the writing user on the server, and prevent password access.
The "read-only" users could be allowed a well-known password.
This isn't as "clever" or "elegant" as configuring the SVN server configs, but it works pretty darned well as long as the users keep their SSH keys secret.
Restrict commit access with a start-commit hook.
Description
The start-commit hook is run before the commit transaction is even
created. It is typically used to decide whether the user has commit
privileges at all.
If the start-commit hook program returns a nonzero exit value, the
commit is stopped before the commit transaction is even created, and
anything printed to stderr is marshalled back to the client.
Input Parameter(s)
The command-line arguments passed to the hook program, in order, are:
Repository path
Authenticated username attempting the commit
Colon-separated list of capabilities that a client passes to the server, including depth, mergeinfo, and log-revprops (new in
Subversion 1.5).
Common uses
Access control (e.g., temporarily lock out commits for some reason).
A means to allow access only from clients that have certain
capabilities.
Is it possible to setup an SVN authz file to use linux server groups?
To try to give a bit more detail/an example, say I have and SVN authz file as follows:
[groups]
developers = linuxUserA, linuxUserB
reviewers = linuxUserC
endUsers = linuxGroupA <- can I insert a Linux group here
[/project]
#developers = rw
#reviewers = r
[/project/downloads/]
#endUsers = r
userA, userB and userC all exist as Linux users, and are granted access as expected. However, members of linuxGroupA don't seem to be granted access (in this example to the downloads folder).
So, can the svn authz be configured to refer to a linux group, whose members will get access (to say the downloads folder above)?
No
Right side inside [groups] section is always list of authz-file's objects (another groups, aliases, users)
You can build string endUsers = ... by processing /etc/group and outputting linuxGroupA's final users into authz file
I'm using Gitolite.
This is my folder Structure:
/var/www/demo.com/user1
/var/www/demo.com/user2
/var/www/demo.com/user3
I have created one repository named demo.git.
I have created three gitolite users user1, user2 and user3.
Now, my question is that when user1 clone or commit or push or pull changes, then it only should change user1's working directory, and same as user2 and user3.
How would you enforce that with Gitolite?
When user1 pull, it will always changes only his/her own working directory.
But when user1 pushes, he/she pushes to one gitolite-manage repo.
If you need to offer personal branch per user, you can look at the gitolite personal branches, in order to enforce user1 to push only in a specific branch.
A user "alice" (if she's in the userlist) can then push any branches inside personal/alice/.
Which means she can push personal/alice/foo and personal/alice/bar, but NOT personal/alice.
(Background: at runtime the "USER" component will be replaced by the name of the invoking user. Access is determined by the right hand side, as usual).
Compared to using arbitrary branch names on the same server, this:
Reduces namespace pollution by corralling all these ad hoc branches into the "personal/" namespace.
Reduces branch name collision by giving each developer her own sub-hierarchy within that.
Removes the need to think about access control, because a user can push only to his own sub-hierarchy.
I wanna know, how I can set user name and password for each user in TortoiseSVN and I already did these steps to made repository:
- Created a file then created repository in this file.
- Changed " svnserve.conf " in conf file.
- Then set all user and them passwd in conf file.
- I changed authz to access my repository also including in conf file.
I try and try to Authentication many of users for each project but as file not Http.
I hope to someone help me in this issue.
I'm having trouble understanding your question, but it sounds to me like you ought to move to integrating Apache with SVN. That will give you the ability to give users different levels of access on a per-directory basis.
Refer to the sectino Per-Directory Access Control in the svn book:
It's possible to set up finer-grained
permissions using a second Apache
httpd module, mod_authz_svn. This
module grabs the various opaque URLs
passing from client to server, asks
mod_dav_svn to decode them, and then
possibly vetoes requests based on
access policies defined in a
configuration file.
Is it possible to write some manner of hook in mercurial that will reject changesets that effect a specific named branch in a repository?
We have a managed project and would like to allow any developers to push their changes to our repository so long as they are in their own named branch. This allows us to manage a single buildbot and a shared sandbox in the same repository (by keeping branches separate). We'd like to block any attempts to write to the default branch from outsiders (we would, internally, merge their branches over).
We're looking at using the pretxnchangegroup hook, but this has 2 concerns:
1) A user can push changes using any username; we basically only have an http-auth protecting the repository by requiring any username or password to actually connect to the repo, but it doesn't check the usernames in the commit to make sure they match the account used to push.
2) Lets say a user has done right and developed in a branch, but then they do one last commit on the default branch. The hg push fails. What does the developer do at this point to fix their push?
Any thoughts?
Yeah, you can do this pretty easily with the pretxnchangegroup like you figured. I'll do it in shell, but it'd be in-process (and thus faster) if you do it in python.
Set up something like this as your pretxnchangegroup:
#!/bin/sh
for thenode in $(hg log -r $HG_NODE:tip --template '{node}\n') ; do
if [ $(hg id --branch -r $thenode) = "default" ] ; then
echo Commits to default branch are not allowed -- bad changeset $thenode
exit 1
fi
done
That makes sure that none of the arriving changesets are on branch "default".
Regarding concern 1: If you're running behind apache you'll have access to the usual CGI variables, so you can check $REMOTE_USER to make sure it matches the branch name if that's something you want to try to enforce.
Regarding concern 2: If a user sees the message that they're pushing an invalid changeset, then they'll just have to push the rest of them using push -r and they can strip or modify their changeset on default later.
Lastly, have you considered just having a separate clone for the auto-builds / main branch? Let everyone push into the staging repo, and let only the buildmaster pull approved changesets from staging into auto-build when s/he is happy with them? You get the same workflow you have now (waiting for a builder to merge), but it's much less hassle.