Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forking produces additional access permissions #616

Closed
gitblit opened this issue Aug 12, 2015 · 5 comments
Closed

Forking produces additional access permissions #616

gitblit opened this issue Aug 12, 2015 · 5 comments

Comments

@gitblit
Copy link
Collaborator

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 320

What steps will reproduce the problem?
1. As an administrator I fork a developers repository (say "projectsA/foo.git")
2. GitBlit prepares the fork and creates it: "~krulls/foo.git"

What is the expected output? What do you see instead?
I expect no changes in the global permission configurations. But after the fork has
been processed several groups and users have additional repository permissions.

For the developer group that has writing permission (RWD) to "projectsA/.*" there now
exists an additional entry in repository permissions: "~krulls/foo.git" -> "R (clone)".

This additional entry has also been added to any user who has specified repository
permissions.

What version of the product are you using? On what operating system?
1.3.1

Please provide any additional information below.
1. User management via LDAP; 
2. a group "all devs" has following access permissions: ".*" -> "R (clone)"
3. a group "devgroup1" has following access permissions: "projectsA/.*" -> "RWD" 
-> that is: a user has clone permission to every repo but writing permission only to
a repo-group according to his team.
4. forking is only allowed to administrators

Reported by stephan.krull.ecg on 2013-10-09 08:04:38

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

So after every fork I have to edit access permissions and delete these additional entries
for up to 4 groups and 10 users. I have to delete the entries because they override
global permissions. A developer who can write to every repo under "projectsA" is suddenly
not able to write to a new fork under "projectsA/foo.git" because of this issue.

Reported by stephan.krull.ecg on 2013-10-09 08:09:38

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Hmm.  I'll look into this.

Reported by James.Moger on 2013-10-11 01:03:35

  • Status changed: Accepted
  • Labels added: Milestone-1.4.0

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Sorry for taking a ridiculous amount of time to get back to this issue.  The behavior
you are seeing was (mostly) the design as documented here.

http://gitblit.com/administration.html#H20

I didn't check the user or teams for whether or not they could already clone the new
fork, I just rammed clone permissions into those objects.  Bad idea.  I'll fix that.

It's not clear to me why your personal fork breaks permissions for devgroup1 with projectsA/.*
-> RWD.  Or was it the unexpected additional explicit permission that was the problem?

Forking in a corporate evironment is one of those grey areas where I wasn't sure how
to setup the default permissions.  I went with team/workgroup transparency which is
why those clone permissions are injected.  If you fork a repo, everyone gets to see
it, by default.

Anyway, I'll fix the unnecessary extra permissions and wait to hear if that is satisfactory
for you.

Reported by James.Moger on 2014-02-27 04:44:34

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Fix pushed to master: CLONE permission no longer explicitly set if the user/team already
has an implied CLONE permission to the fork: regex, admin flag, future something or
other.

The other rule for transparency/collaboration still applies: if the user/team does
not have an implied CLONE permission for the fork BUT does have a CLONE permission
for the source, the user/team gets an explicit CLONE permission for the fork.

Reported by James.Moger on 2014-02-27 05:05:00

  • Status changed: Queued

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

1.4.0 released.

Reported by James.Moger on 2014-03-09 18:06:21

  • Status changed: Done

@gitblit gitblit closed this as completed Aug 12, 2015
@flaix flaix modified the milestone: 1.4.0 Dec 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants