Fossil

Login Groups
Login

Login Groups

The Admin → Login-Groups UI feature and its corresponding login-group command solve a common problem with Fossil: you’ve created multiple repositories that some subset of users need access to, and you don’t want to redundantly administer the user credentials for each repository.

Restrictions

This feature ties changes to the “user” table in one repo to that in one or more other repos, keyed by the user’s name. The interactions are non-obvious because although the goal is for the end result to “just work,” there are practical security and administration matters that complicate things:

  1. Login group handling only works between joined repositories for the subset of users with the same name.

  2. If you’re logged in on one repo in a group, any other repo in that group that has a matching user record will accept your valid login.

  3. When you set up a login group between two repos, the user tables aren’t merged, so even though you may have users that appear in both, they will retain their initial passwords, credentials, and so forth.

  4. The same is true after the login group is created: changes you make to the user table in one repo in the group only propagate to the other repos in the group when you check the “Apply changes to all repositories“ box in the “Scope” section of the user edit screen. Otherwise, user changes remain local to the repo you made them on.

  5. Login groups only affect the HTTP interfaces. Contrast things like ssh:// clones, where unless you go out of your way to force them to run over one of the HTTP interfaces that pays attention to Fossil’s RBAC system, login groups aren’t consulted.

Interactions

These restrictions combine in subtle and interesting ways. Examples:

Discussion

The end result of all of this is that you can have a subset of users with credentials only on repo A, a different subset only on B, and a third subset common to both. The only thing selecting which case applies is restriction #1 above.

Login groups have names. A repo can be in only one of these named login groups at a time.

Trust in login groups is transitive within a single server. Consider this sequence:

  $ cd /path/to/A/checkout
  $ fossil login-group join --name G ~/museum/B.fossil
  $ cd /path/to/C/checkout
  $ fossil login-group join ~/museum/B.fossil

That creates login group G joining repo A to B, then joins C to B. Although we didn’t explicitly tie C to A, a successful login on C gets you into both A and B, within the restrictions set out above.

Changes are transitive in the same way, provided you check that “apply to all” box on the user edit screen.


Back to Administering User Capabilities