|
1
|
# Login Groups |
|
2
|
|
|
3
|
The Admin → Login-Groups UI feature and its corresponding [`login-group` |
|
4
|
command][lg] solve a common problem with Fossil: you’ve created multiple |
|
5
|
repositories that some subset of users need access to, and you |
|
6
|
don’t want to redundantly administer the user credentials for each |
|
7
|
repository. |
|
8
|
|
|
9
|
|
|
10
|
## Restrictions |
|
11
|
|
|
12
|
This feature ties changes to the “`user`” table in one repo to that in |
|
13
|
one or more other repos, keyed by the user’s name. The interactions are |
|
14
|
non-obvious because although the goal is for the end result to “just |
|
15
|
work,” there are practical security and administration matters that |
|
16
|
complicate things: |
|
17
|
|
|
18
|
1. Login group handling only works between joined repositories for the |
|
19
|
subset of users with the same name. |
|
20
|
|
|
21
|
1. If you’re logged in on one repo in a group, any other repo in that |
|
22
|
group that has a matching user record will accept your valid login. |
|
23
|
|
|
24
|
1. When you set up a login group between two repos, the user tables |
|
25
|
aren’t merged, so even though you may have users that appear in |
|
26
|
both, they will retain their initial passwords, credentials, and so |
|
27
|
forth. |
|
28
|
|
|
29
|
1. The same is true after the login group is created: changes you make |
|
30
|
to the user table in one repo in the group only propagate to the |
|
31
|
other repos in the group when you check the “Apply changes to all |
|
32
|
repositories“ box in the “Scope” section of the user edit screen. |
|
33
|
Otherwise, user changes remain local to the repo you made them on. |
|
34
|
|
|
35
|
1. Login groups only affect [the HTTP interfaces][wo]. Contrast things |
|
36
|
like `ssh://` clones, where unless you [go out of your way][sh] to |
|
37
|
force them to run over one of the HTTP interfaces that pays |
|
38
|
attention to Fossil’s RBAC system, login groups aren’t consulted. |
|
39
|
|
|
40
|
|
|
41
|
## Interactions |
|
42
|
|
|
43
|
These restrictions combine in subtle and interesting ways. Examples: |
|
44
|
|
|
45
|
* **#1 and #2**: If you are logged into repo C as “charlie” and then |
|
46
|
try to visit joined repo A where “charlie” doesn’t exist, your valid |
|
47
|
login on C won’t get you into A. |
|
48
|
|
|
49
|
* **#2 and #3**: If “alice” exists in both of these same repos, |
|
50
|
logging in on A gets her into C, but if she has different user |
|
51
|
capabilities on each from the time before the two repos joined the |
|
52
|
login group, her caps on A don’t apply to C, nor vice versa. |
|
53
|
|
|
54
|
Let us say F is a forum-only repo, and W is a wiki-only repo, and |
|
55
|
that Alice has forum-posting rights on F and wiki-editing rights on |
|
56
|
W. If both repos are joined by a login group, Alice can log in on F |
|
57
|
and then access W without logging in on it separately, but she |
|
58
|
cannot then post a forum message on W even though she could on F. |
|
59
|
|
|
60
|
* **#3 and #4**: If you change the caps for user “alice” on one repo |
|
61
|
in a group and tell Fossil to apply the changes to all repos in the |
|
62
|
group, the new caps will *overwrite* those on the other repos, not |
|
63
|
merge with them. |
|
64
|
|
|
65
|
To extend the practical example from the prior point, let us say you |
|
66
|
wish to grant Alice the “write unversioned” capability on both F and |
|
67
|
W. If you check that single user cap box on F plus the “apply to |
|
68
|
all” option, then “Apply Changes,” she will end up with forum + |
|
69
|
unversioned caps on repo W, losing her wiki-editing caps in the |
|
70
|
process. |
|
71
|
|
|
72
|
If you want user caps to differ on each repo, you must administer |
|
73
|
them separately even if there is a common subset of caps between all |
|
74
|
repos in the group for that user. Remember: selecting the “apply to |
|
75
|
all” box calls for an overwrite operation, not a merge. |
|
76
|
|
|
77
|
* **#4 and #1**: If you make a change to an existing user “bob” in |
|
78
|
repo B and select the “apply to all” option, it will only affect |
|
79
|
other repos in the group that have a user “bob” configured. |
|
80
|
|
|
81
|
But, if you are instead creating user “bob” for the first time and |
|
82
|
select that option, that user *will* be created in all repos. The |
|
83
|
same is true of user deletion: that destructive action will |
|
84
|
propagate through the group if you request it. |
|
85
|
|
|
86
|
* **#5 and #1**: If you have a user “daisy” on both repos A and B in a |
|
87
|
login group, logging in over the web to A doesn’t let you push |
|
88
|
changes into B over SSH. Without the workaround linked above, SSH |
|
89
|
only pays attention to the operating system’s user authentication |
|
90
|
system, not Fossil’s. |
|
91
|
|
|
92
|
Inversely, if Daisy successfully logs in over SSH to repo B, she |
|
93
|
gains no access to any of the other repos in that group. She needs |
|
94
|
at least one valid login over HTTP to one of the group’s repos. |
|
95
|
|
|
96
|
|
|
97
|
## Discussion |
|
98
|
|
|
99
|
The end result of all of this is that you can have a subset of users |
|
100
|
with credentials only on repo A, a different subset only on B, and a |
|
101
|
third subset common to both. The only thing selecting which case applies |
|
102
|
is restriction #1 above. |
|
103
|
|
|
104
|
Login groups have names. A repo can be in only one of these named login |
|
105
|
groups at a time. |
|
106
|
|
|
107
|
Trust in login groups is transitive within a single server. Consider |
|
108
|
this sequence: |
|
109
|
|
|
110
|
$ cd /path/to/A/checkout |
|
111
|
$ fossil login-group join --name G ~/museum/B.fossil |
|
112
|
$ cd /path/to/C/checkout |
|
113
|
$ fossil login-group join ~/museum/B.fossil |
|
114
|
|
|
115
|
That creates login group G joining repo A to B, then joins C to B. |
|
116
|
Although we didn’t explicitly tie C to A, a successful login on C gets |
|
117
|
you into both A and B, within the restrictions set out above. |
|
118
|
|
|
119
|
Changes are transitive in the same way, provided you check that “apply |
|
120
|
to all” box on the user edit screen. |
|
121
|
|
|
122
|
[lg]: /help/login-group |
|
123
|
[sh]: ../server/any/http-over-ssh.md |
|
124
|
[wo]: ./index.md#webonly |
|
125
|
|
|
126
|
----- |
|
127
|
|
|
128
|
*[Back to Administering User Capabilities](./)* |
|
129
|
|