CODEWITHSUNDEEP
gitgitlabgit-branchaclreadonly
Johnny Utahh
Johnny Utahh

Reputation: 2478

Git: disable read access on a per-branch basis for individual git users?

Summary

How can our team disable branch "read access" for individual git users? Does the market offer any existing tools for self-hosted environments? Or is there some other, better means to provide "disabled read access" to git files/directories?

Thus far, we think we might prefer git-branch-based access-control, as a) branch-based control seems better than b) directory-based control, as (a) seems able to do everything (b) can, and more.

We realize this is a tall order for a tool (git) that is designed to copy everything (in a repo) to a clone (of said repo). We're skeptical, but still curious to see if creative solutions exist or might be invented/discoverable.

Preferred features

  1. RACL (read-access-control lists) for any branch, including for unlimited # of any individual branches for any set or combination of git users.

  2. [Optional] Integration with any git repo client/server software. This way we can theoretically integrate with most any git-based tool/ecosystem. However if a special/custom git tool set is required, we'll explore using that.

  3. [Optional] Seamless GitLab integration. We do not yet see GitLab offering this feature. (We do not yet see protected branches with a "disable reads" feature.)

  4. [Optional] Self-hosted git repo. We self-host services, including git, for our critical projects whenever possible. But we'll consider working with hosted services if that's the only way, for now.

More details

We've not yet empirically tested any of the claimed features from various, self-hosting-feature tool providers. But we've performed a tiny bit of research. Nothing we've seen yet outright claims features for "disabled-read privacy"; Gitolite maybe does?

There seems to be more market focus on "protecting" branches to avoid data-loss scenarios. Instead, with this discussion, I'm more interested in preventing (read) access of designated users to sensitive information.

One could make a different git repo for each "group/class" of access, but that's problematic for numerous reasons, including but not limited to:

Enabling unlimited "private" git branches within a common, larger repo seems like a more-effective path.

Upvotes: 2

Views: 1517

Answers (2)

GuillaumeC
GuillaumeC

Reputation: 11

Instead of Gitlab, you could use Gerrit (https://www.gerritcodereview.com/)
which allows you to enable ACL read access per reference (https://gerrit-review.googlesource.com/Documentation/access-control.html#_project_access_control_lists)

As an example, to allow private/public sandbox for each registered user:

Repository "All-Projects", "Access":

Reference:refs/*
remove Read for Anonymous Users

Reference:^refs/heads/users/.+/public/.+
Allow Read "Registered Users"

Reference:refs/heads/users/${username}/public/*
Allow Create Reference, Delete Reference, Push (w/ or w/o force), Read for Registered Users

Reference:refs/heads/users/${username}/private/*
Allow Create Reference, Delete Reference, Push (w/ or w/o force), Read for Registered Users

I don't know if it's possible to use the special "${username}" with the regexp to write only one rule.

Upvotes: 1

VonC
VonC

Reputation: 1324977

The simplest solution with Gitlab to limit write-access is:

  • protect the branches.
  • request contribution though merge request (meaning fork)

But to limit read access, you need a separate repository, private, which will include the private branches.

Anything in your public repository is be definition readable.

Upvotes: 1

Related Questions