Re: [gitolite] Is it possible to allow users to control their wild-repos in a subconf?

[Jan Vales]

Hello,

why would you want to allow users to configure their wild repos, or even have access to the gitolite admin repo at all?
Arent wild repos supposed to be general enough, that users dont need to edit anything?

I wouldnt risk giving any non-@admin-user access to the gitolite admin repo: that would leak waaaay too much information
about other groups, repo configs, custom hooks code, users, their pubkeys or usernames, which no one really needs to
know, also GDPR.

If its about access rights, lets jump back to my previous mail.

repo priv/CREATOR/[a-zA-Z0-9_-]*
C = @admins @all
RW+ = CREATOR
RW = MANAGER
- master$ = @all
RW = WRITERS
R = READERS

This way I defined that there are manager (yeah, i called the role manager, without the s, because of better fitting a
monosize word-length), writers and readers. (do that in gitolite.rc ?)
READERS can only read.
WRITERS can push to any branch that is not the master branch.
MANAGER can push to any branch.
CREATOR can also rebase.

The creator (user2) can assign users to these roles with:

$ ssh git@git... perms priv/user2/best-repo + WRITERS user3 #allow user3 to push to non-master-branches
$ ssh git@git... perms priv/user2/best-repo + MANAGER user4 #allow user4 to push to the master-branch
$ ssh git@git... perms priv/user2/best-repo - READERS user1 #remove user1 from READERS
$ ssh git@git... perms priv/user2/best-repo -lr #list role-assignments


This config seems to work well for basically everyone. But I have a few special wild repo configs for some groups that
look basically like this:

repo group1/[a-zA-Z0-9_-]*
C = @admins @group1
RW+ = CREATOR
RW = MANAGER @group1
- master$ = @all
RW = WRITERS
R = READERS

This way, everyone in @group1 automatically has access to all group1-repos.
Only users from group1 can create new repos in that group space.
CREATOR can still give access to other users that are not in group1, see above.


Untested:
(The need for such a construct never happened and im not sure if it still/really works)
If needed one could add a BANNED role, so creators can remove access from a repo for users which would otherwise be
allowed, but whole I played with that in the past, the need never arose. Could possibly look something like this:

repo group2/[a-zA-Z0-9_-]*
C = @admins @group2
RW+ = CREATOR @admins
- = BANNED
RW = MANAGER @group2
- master$ = @all
RW = WRITERS
R = READERS

That way, I think (see "untested"), the CREATOR could be allowed to ban any non-@admin-user from pulling from the repo,
if CREATOR adds the user to the BANNED role.


br,
Jan



On 30/06/2022 17:05, Jonathan Vorndamme wrote:
> Hello,
>
> I want every user to be able to edit a subconf conf/subconf/<username>.conf and allow them to control the repos they can
> setup as wild repos. As I have quite a lot of users, so I need an automatic way to set this up for every imported user.
> I have something like this in mind:
>
> *$USER$ = users/$USER$/[a-zA-Z0-9\.\-_]+*
>
> repo    gitolite-admin
>         RW+                                            =   @itadmin
> # sub-configurations for delegating administration
>         RW                                             =   @developers
>         R                                              =   @all
>         RW+ VREF/NAME/                                 =   @itadmin
> *RW  VREF/NAME/conf/subconfs/$USER$             =  $USER$*
>         -   VREF/NAME/
>
> subconf "subconfs/*.conf"
>
> repo    users/CREATOR/[a-zA-Z0-9\.\-_]+
>         C       =   @all
>         RW+     =   CREATOR
>
> where $USER$ should evaluate to the name of the current gitolite user. So every user shall be able to setup a subconf
> for his username and should be able to control all the wildcard repos he is allowed to setup via that file, but I don't
> want to list every user explicitly. Is this possible (without programming my own hooks/VREFs)? If so, how?
>
> Best regards
> Jonathan Vorndamme
>
> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com
> <mailto:gitolite+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gitolite/02852081-f335-48ef-926c-46985cc2e26bn%40googlegroups.com
> <https://groups.google.com/d/msgid/gitolite/02852081-f335-48ef-926c-46985cc2e26bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Nick]

I would just like to chime in with a +1 here. Jan is right. Just set up basic ACLs and let people use `gitolite perms` to manage the rest.

Jan's config looks almost identical to the one I ended up coming up with:


repo datasets/..*
# we restrict repo creation so that the master branch is protected even on first push
C = @admins
RW+D = OWNERS
- master = @all # master is a protected branch
RW+ = WRITERS
R = @all
# make sure @admins own everything
option default.roles-1 = OWNERS @admins
# this line is to glue the legacy single CREATOR into the newer OWNERS group.
# see https://gitolite.com/gitolite/wild#appendix-1-owner-and-creator
option default.roles-2 = OWNERS CREATOR

I was trying to model GitHub's rules because, obviously, my team is used to GitHub. We recently decided to limit CREATORS to @admins, because master isn't protected from its creator and we want @admins be our reviewers/merge masters (what Jan added the MANAGER group for).

The 'option default' lines create *.git/gl-perms files in each repo, which look like

OWNERS @admins
OWNERS kousu

meaning that @admins are always OWNERS, as well as the creator (in this case, me).

You can make your life a lot easier with these since then you don't depend on your creators being well trained in Gitolite (my users are definitely not, they interact with it for probably 100 minutes over the entire time they are with us before moving on to a different project/group). For example, these could be added to Jan's setup to set up a repos where @group1 can submit branches, but master is protected from everyone except for @group1-reviewers

option default.roles-1 = OWNERS @admins
option default.roles-2 = MANAGER @group1-reviewers
option default.roles-3 = READER @group1
option default.roles-4 = WRITER @group1

November 30, 2022 8:26 PM, "Jan Vales" <j...@jvales.net> wrote:

> Hello,
>
> why would you want to allow users to configure their wild repos, or even have access to the
> gitolite admin repo at all?
> Arent wild repos supposed to be general enough, that users dont need to edit anything?
>
> I wouldnt risk giving any non-@admin-user access to the gitolite admin repo: that would leak waaaay
> too much information
> about other groups, repo configs, custom hooks code, users, their pubkeys or usernames, which no
> one really needs to
> know, also GDPR.
>
> If its about access rights, lets jump back to my previous mail.
>
> repo priv/CREATOR/[a-zA-Z0-9_-]*
> C = @admins @all
> RW+ = CREATOR
> RW = MANAGER
> - master$ = @all
> RW = WRITERS
> R = READERS
>

[Jonathan Vorndamme]

Hello,

thanks a lot for your answers. I don't think I can get my users to use the perms command (correctly) and I don't have the time to do it for all of them. Sharing the repo configs with all users seems like a good thing to me as people have examples on how to correctly configure their repos and also it is some automatic way of sharing the knowledge about what is there. But about the GDPR - is any of the data in the gitolite admin repo considered private? All the user data apart from the public key which is published on network drive shared among all (possible) users, is on the public website anyways (and much more). And the configuration itself doesn't seem to be personal data to me. Can you elaborate a bit more on that?

Best regards

Jonathan