Granular read access for GitHub monorepos

Question

We will be posing hundreds of coding challenges to hundreds of users. Each user can post their own solution to any number of challenges, resulting in possibly thousands of challenge solutions. Creating hundreds or thousands of separate repos seems unwieldy, so we'd like to keep the entire project under a monorepo and limit read-access on a per-file or per-directory basis for each user. Each user should only be able to see their own files, while the owners of the repo should be able to see all files.

An example repo structure would look like this:

challenges/
├── challenge1/
│   ├── challenge1-user1/
│   ├── challenge1-user2/
│   └── challenge1-user5/
│       ...
├── challenge2/
│   ├── challenge2-user2/
│   └── challenge2-user3/
│       ...
├── challenge3/
│   ├── challenge3-user1/
│   ├── challenge3-user3/
│   └── challenge3-user4/
│       ...
├── ...
...

Also interested if other people have had to deal with similar problems and their solutions.

Answer 1

To my knowledge github does not provide this type of functionality, as github (and open source in general) is geared towards visibility and transparency and it wouldn't make much sense for it to provide this.

I suppose it is possible to restrict pushes to the main branch, but allow people to create and push their own branches with their solutions and clone each branch before deleting its remote and storing the clone somewhere else. I wouldn't suggest this as there will be some delay between when the branch is pushed and when the branch is cloned and deleted allowing for a third party to also clone another users solutions.

I imagine you can do this via github workflows; however, this is still probably not an ideal solution or what workflows were originally designed to do.

Answer 2

You cannot provide this kind of restricted access to a Git repository. The documentation for Git namespaces explains why:

The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.

As documented, if you have data that needs to have different access controls, it needs to live in a different repository. A monorepo is not going to work here.