1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
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?
|
