Rhodecode Setup =============== SSH Keys and access to public repos =================================== The main goal is to have the same ACL when connecting to our git server via SSH protocol as the one over the Rhodecode web interface. All the user/group restrictions must apply as well for both read/write access. To manage this, all the groups and users from the Rhodecode database must be mirrored and synced with system users and groups. Couple of potential problems were observed and discussed. Rhodecode system user --------------------- The Rhodecode app uses the 'rhodecode' system user for all git and mercurial interactions so this user must have read/write access over all repositories. Easiest way to do this and not intefere with other permissions is to have all repository directories user ownership given to this user. Group ownerships will be used to control SSH user/group ACL. The question is does having a user which can access all repositories present a security threat? For one, we can disable shell access after installation for this user as well. See section on "Disabling shell access for git SSH users". Nested groups ------------- Since Rhodecode supports nested groups and the need for them will most likely be present, there are couple of ways to mimic this feature with the system groups. Both ways include some form of synchronization between Rhodecode users/groups with the systems' one. First solution assume that all users and groups on Rhodecode reflects those on the system. It includes having the sync script assign particular system user not only to the group which he is assigned to in Rhodecode, but to all *parent* groups of this particular group. Second solution includes having all the users from the Rhodecode synced in the system as well, but not all of the groups. Group will exist in the system only and only if it is the *mother* group (meaning it has no parent) and it has at least one user belonging to either that group or any child group. Disabling shell access for git SSH users ---------------------------------------- In order for users to have access to git using SSH keys for public repositories the idea provide them with limited access to git+ssh protocol. SSH keys will be picked up by Rhodecode from LDAP service. Users will be deprived of shell access to the system by enabling git-shell for each user via the .ssh/authorized_keys file. command="git-shell -c $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC***...*** For more info on git-shell and what commands it supports please refer to the manual. Private Repositories ==================== RhodeCode supports private repositories out-of-the-box. It should not be necessary to setup a separate domain to handle private repositories, RhodeCode can handle access level through its users and groups database. Repositories can be marked private, and access can be granted either at group and/or user level. A user can create repositories and set them private as well. Access to the repository is granted by its creator to other user. A user is admin of the repositories she creates. All configurations happen from the RhodeCode web interface, when logged in as the 'admin' user, or as an user with the 'admin' status ('admin' status in this case is web-site wise, not per-repository). In order for a group to be set up as private, it is necessary to change its 'default' setting to 'none', so that only explicitly added groups or users can view it. Anonymous users will not see it either. When a user that does not have access to a repository try to access it via its URL, a 403 page is returned if the user is logged in, or the login interface is shown if the user is anonymous. Scenarios --------- * Private group called 'linaro-private', a logged in user called 'johndoe': * User has no permissions on the 'linaro-private' group: - Does not see the repository - If he tries to access the repository URL, 403 page is shown * User has 'read' permissions on the group: - Can see and browse the 'linaro-private' group repositories - Cannot add new repositories under 'linaro-private' * User has 'write' permissions on the group: - Can see and browse the 'linaro-private' group repositories - Can add new repositories under 'linaro-private' * Anonymous user: - She sees nothing on the home page - If she tries to access the repository, the login interface is shown * Private group called 'linaro-private', a sub group called 'sub-linaro-private', a user 'johndoe': * User has no permissions on the parent group nor the sub-group: - Does not see the repositories - If he tries to access the repository URL, 403 page is shown * User has no permissions on the parent group, has 'read' access on the sub-group: - Cannot see the parent group - Can access the sub-group only via its URL: domain/group/sub-group * User has 'read' permissions on the parent group, and none in sub-group: - Does see the parent group repositories - Cannot access the sub-group * User has 'write' permissions on the parent group, 'read' on the sub-group: - Does see parent and sub-group repositories - Can access sub-group - Can create new repositories in the parent group, but not in the sub-group Open Questions -------------- * How will this cope with SSH access to repositories?