Re: Question: What's the best way to implement directory permission control in git?

[Han-Wen Nienhuys <hanwen@google.com>]

On Sat, Jul 30, 2022 at 1:50 AM Emily Shaffer <emilyshaffer@google.com> wrote:
> Gerrit has tried to support something sort of similar to this -
> per-branch read permissions. They were really painful! So much so that
> our Gerrit team is actively discouraging their use, and in the process
> of deprecating them. It turns out that on the server side, calculating
> permissions for which commit should be visible is very expensive,
> because you are not just saying "is commit abcdef on
> forbidden-branch?" but rather are saying "is commit abcdef on
> forbidden-branch *and not on any branches $user is allowed to see*?"
> The same calculation woes would be true of per-object or per-tree
> permissions, because Git will treat 'everyone/can/see/.linter.config'
> and 'very/secret/dir/.linter.config' as a single object with a single
> ID if the contents of each '.linter.config' are identical. It is still
> very expensive for the server to decide whether or not it's okay to
> send a certain object. Part of the reason the branch ACL calculation
> is so painful is that we have some repositories with many many
> branches (100,000+); if you're using a very large monorepo you will
> probably find similarly expensive and complex calculations even in a
> single repository.


Thanks Emily,

I agree with your points, but as the manager of Google's Gerrit team,
I just wanted to add a few clarifications:

* The max number of branches we have on repositories is O(1000s). IIRC
our Android repositories are the worst offenders, because there is a
combinatorial explosion of {major release, minor release, target
device}. Pending reviews number in the millions, but we usually don't
have to evaluate ACLs fully, as the review refs aren't downloaded
commonly.

* The read ACLs are assigned to {branch-regexp, group} tuples. This
means that you can't precompute visibility either, because each
individual user may be in a different set of groups.

* Even disconsidering that, you can still do optimizations if updates
are FF (because each update only increases the visibility of each
commit). However, non-FF branch updates preclude such precomputations.
(Gerrit has non-FF updates in a number of places).

* The Gerrit team isn't actively deprecating read ACLs: the problem is
hard, because removing read ACLs on branches means that the read ACLs
move to repository level, which implies setting up complex ACL
configuration and replication infrastructure for repositories to
address existing use cases. It's currently just one of these features
that we wish hadn't been added, but now that it's there, we suffer
through it.

More generally, read permissions are hard to get right in a monorepo:
even if you stop developers from accessing the code through Git fetch,
the permissions must also be enforced throughout the entire dev stack,
including code browsing, code search, viewing CI artifacts etc.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Liana Sebastian