Read/Push to a subtree limitation #1876

New Issue

GiteaMirror · 2025-11-02T04:16:12-06:00

GiteaMirror commented

2025-11-02 04:16:12 -06:00

Originally created by @publicocean0 on GitHub (Jun 6, 2018).

i gave a look at gitea it is very interesting . Anyway i saw maybe a functional limitation:
it is not possible to limit action for a developer in a specific subtree and branch

Originally created by @publicocean0 on GitHub (Jun 6, 2018). i gave a look at gitea it is very interesting . Anyway i saw maybe a functional limitation: it is not possible to limit action for a developer in a specific subtree and branch

GiteaMirror added the type/proposal type/feature labels 2025-11-02 04:16:12 -06:00

GiteaMirror closed this issue

2025-11-02 04:16:13 -06:00

GiteaMirror commented

2025-11-02 04:16:13 -06:00

@axifive commented on GitHub (Jun 6, 2018):

This is already present in the repo settings:
Settings => Branches => Branch Protection

@axifive commented on GitHub (Jun 6, 2018): This is already present in the repo settings: **Settings** => **Branches** => **Branch Protection** ![2018-06-06 16 40 26](https://user-images.githubusercontent.com/844963/41041668-5ba03730-69a8-11e8-9493-9359ba53d1dd.png)

GiteaMirror commented

2025-11-02 04:16:14 -06:00

@publicocean0 commented on GitHub (Jun 6, 2018):

if i want a collaborator cant see a branch? or cant read the entire project but just a subfolder where he can work in a specific branch?

@publicocean0 commented on GitHub (Jun 6, 2018): if i want a collaborator cant see a branch? or cant read the entire project but just a subfolder where he can work in a specific branch?

GiteaMirror commented

2025-11-02 04:16:14 -06:00

@daviian commented on GitHub (Jun 6, 2018):

I would argue that hiding branches isn't possible because git itself doesn't provide that functionality.
Pushing to a subtree may be realizable although I don't see the real benefit.
Extracting that code into a separate component / repository may be a cleaner way to achieve this kind of functionality.
Furthermore if it is sufficient for the developer to only see a certain subtree / folder the code is already modular enough to separate them.

@daviian commented on GitHub (Jun 6, 2018): I would argue that hiding branches isn't possible because git itself doesn't provide that functionality. Pushing to a subtree may be realizable although I don't see the real benefit. Extracting that code into a separate component / repository may be a cleaner way to achieve this kind of functionality. Furthermore if it is sufficient for the developer to only see a certain subtree / folder the code is already modular enough to separate them.

GiteaMirror commented

2025-11-02 04:16:14 -06:00

@markuman commented on GitHub (Jun 6, 2018):

I don't think git is working that way. A collaborator will always see any branches of a repository, but push access can be restricted to branches.

@markuman commented on GitHub (Jun 6, 2018): I don't think git is working that way. A collaborator will always see any branches of a repository, but push access can be restricted to branches.

GiteaMirror commented

2025-11-02 04:16:14 -06:00

@publicocean0 commented on GitHub (Jun 6, 2018):

i m used to work with gitolite where it is possible

@publicocean0 commented on GitHub (Jun 6, 2018): i m used to work with gitolite where it is possible

GiteaMirror commented

2025-11-02 04:16:14 -06:00

@lunny commented on GitHub (Jun 6, 2018):

Read/Push to a subtree limitation maybe a new feature. Don't know how gitolite did it.

@lunny commented on GitHub (Jun 6, 2018): Read/Push to a subtree limitation maybe a new feature. Don't know how gitolite did it.

GiteaMirror commented

2025-11-02 04:16:15 -06:00

@daviian commented on GitHub (Jun 6, 2018):

@publicocean0 Do you mean subtree of the files or a subtree of branches? Just that we are talking about the same thing ;-)

@daviian commented on GitHub (Jun 6, 2018): @publicocean0 Do you mean subtree of the files or a subtree of branches? Just that we are talking about the same thing ;-)

GiteaMirror commented

2025-11-02 04:16:15 -06:00

@publicocean0 commented on GitHub (Jun 6, 2018):

with gitolite you can decide where a developer can push, pull , read , write .
it is quite simple you create a regular expression about path in the project with associated permissions.
/ab/cd/a/* R dev1,dev2,dev3
/ac/rf/* RW dev4,dev5,...
/ar/u/RW+ dev6,dev7
....

@publicocean0 commented on GitHub (Jun 6, 2018): with gitolite you can decide where a developer can push, pull , read , write . it is quite simple you create a regular expression about path in the project with associated permissions. /ab/cd/a/* R dev1,dev2,dev3 /ac/rf/* RW dev4,dev5,... /ar/u/RW+ dev6,dev7 ....

GiteaMirror commented

2025-11-02 04:16:15 -06:00

@tfheen commented on GitHub (Apr 2, 2019):

Pushing to a subtree may be realizable although I don't see the real benefit.

My particular use case is that I have a repository where machines should be able to push to a particular file with their state in, but not otherwise change the state of that repository. They should also not be able to influence state from other machines. Doing the same thing with submodules and symlinks, while possible, would be a lot more work and hassle.

It is, as you note, not possible to restrict reading to subtrees due to how git works, but that's not a concern of mine, I'm only interested in limiting push.

I can see a few different ways to implement support for this, and would like some feedback on options:

Add native ACL functionality. This, while nice, is probably quite a lot of work.
Expose enough information to hooks that it's possible to limit who can push what trees there. This is pretty simple to do.
Add support for adding environment variables as metadata to SSH keys. This can have unexpected side effects (what happens if somebody is able to influence, say, PATH when a hook is called?), but allows implementing per-branch support similar to the previous point.
Add support for validating webhooks, so a push would cause a webhook to be called, and depending on the result of the webhook, it would fail or succeed the push. This would require exposing enough information that the webhook is able to make an informed judgement about the push, but also allows the most flexibility since those can then also be used for arbitrary other kinds of admission controls.

I'm happy to spend some time on this, since I'd like to have the functionality, but would like the direction to be aligned with what you'll accept into the project. If you have other approaches you think would be viable and wanted, I'm of course happy to discuss those.

@tfheen commented on GitHub (Apr 2, 2019): > Pushing to a subtree may be realizable although I don't see the real benefit. My particular use case is that I have a repository where machines should be able to push to a particular file with their state in, but not otherwise change the state of that repository. They should also not be able to influence state from other machines. Doing the same thing with submodules and symlinks, while possible, would be a lot more work and hassle. It is, as you note, not possible to restrict reading to subtrees due to how git works, but that's not a concern of mine, I'm only interested in limiting push. I can see a few different ways to implement support for this, and would like some feedback on options: - Add native ACL functionality. This, while nice, is probably quite a lot of work. - Expose enough information to hooks that it's possible to limit who can push what trees there. This is pretty simple to do. - Add support for adding environment variables as metadata to SSH keys. This can have unexpected side effects (what happens if somebody is able to influence, say, PATH when a hook is called?), but allows implementing per-branch support similar to the previous point. - Add support for validating webhooks, so a push would cause a webhook to be called, and depending on the result of the webhook, it would fail or succeed the push. This would require exposing enough information that the webhook is able to make an informed judgement about the push, but also allows the most flexibility since those can then also be used for arbitrary other kinds of admission controls. I'm happy to spend some time on this, since I'd like to have the functionality, but would like the direction to be aligned with what you'll accept into the project. If you have other approaches you think would be viable and wanted, I'm of course happy to discuss those.

GiteaMirror commented

2025-11-02 04:16:15 -06:00

@zeripath commented on GitHub (Apr 5, 2019):

Ok you can do checking of push paths using a pre-receive hook. Admittedly the UI is not as nice as in gitolite but if you did want to move to Gitea it is possible.

@zeripath commented on GitHub (Apr 5, 2019): Ok you can do checking of push paths using a pre-receive hook. Admittedly the UI is not as nice as in gitolite but if you did want to move to Gitea it is possible.

GiteaMirror commented

2025-11-02 04:16:16 -06:00

@tfheen commented on GitHub (Apr 6, 2019):

You can, but it would be massively more useful if you actually had the deploy key which was used for pushing. I'd rather not create a real account for each and every one of my machines (IIRC, the account name of the pusher is exposed as a variable name, but not the key's name).

@tfheen commented on GitHub (Apr 6, 2019): You can, but it would be massively more useful if you actually had the deploy key which was used for pushing. I'd rather not create a real account for each and every one of my machines (IIRC, the account name of the pusher is exposed as a variable name, but not the key's name).

GiteaMirror commented

2025-11-02 04:16:16 -06:00

@zeripath commented on GitHub (Apr 6, 2019):

At present the way I fixed the deploy keys was to make them act as the owner of the repository - this is clearly not ideal. I guess I think sending the hooks the keyid is probably a reasonable half-way house.

If I had to say what the correct answer is - deploy keys are virtual users (acting as the owner but with additional parts to their name) and should be treated as such but that could be difficult to refactor in.

If we could create some kind of virtual user we could actually add true Become User functionality to Gitea with real auditable actions etc.

@zeripath commented on GitHub (Apr 6, 2019): At present the way I fixed the deploy keys was to make them act as the owner of the repository - this is clearly not ideal. I guess I think sending the hooks the keyid is probably a reasonable half-way house. If I had to say what the correct answer is - deploy keys are virtual users (acting as the owner but with additional parts to their name) and should be treated as such but that could be difficult to refactor in. If we could create some kind of virtual user we could actually add true Become User functionality to Gitea with real auditable actions etc.

GiteaMirror referenced this issue

2025-11-02 07:05:59 -06:00

Discussion of v1.15.x Roadmap #6766

GiteaMirror referenced this issue

2025-11-02 07:07:41 -06:00

Mirror Summary #6827

Sign in to join this conversation.