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

user with RWD permissions can't push #555

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

user with RWD permissions can't push #555

gitblit opened this issue Aug 12, 2015 · 11 comments

Comments

@gitblit
Copy link
Collaborator

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 259

What steps will reproduce the problem?

We have an user with RWD access rights, but he can’t push.

This user is in a group with some other users. All users can see the repositories in
gitblit and can clone it. But this user can’t push. It’s not evident why he can’t push.

Effective rights of group:
Regex RWD of some folders (projects/.*)

Effective rights of user A in this group:
Group RWD of some folders (projects/.*)

Effective rights of user B in this group:
Group RWD of some folders (projects/.*)

Effective team permissions of a repository into projects folder:
Regex RWD for this group

Effective user permissions of a repository into projects folder:
User A have RWD rights from group
User B have RWD rights from group

User A and B have the same rights but user A can’t push.

At the next day he try again and he can push to the project.


What is the expected output? What do you see instead?
- I expected that users with effective RWD can push
- I expected "save" update changes on permissions immediately
- I expected "clear cache" have an effect of changes on permissions, if "save" didn't
do this
- I don't expected that users must wait one day befor they can work

What version of the product are you using? On what operating system?
1.2.1 WAR over tomcat 7 on Debian 4.6
client: windows xp, Egit 2.3.x and GitBash 1.8.x

Please provide any additional information below.


Reported by gerd.guehne.ecg.leipzig on 2013-06-20 12:03:20

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

The best way to help me resolve this issue and issue-257 will be to provide me with
a users.conf that exhibits the problem(s).  It can either be a reduced/sanitized file
or a hand-crafted example.

Reported by James.Moger on 2013-06-20 12:08:25

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

additional information:
Yesterday the effective rights of the repositories for user A show clone permissions,
but group permissions was RWD.
Today the repositories show RWD permissions for user A. It's not clear why this is
differently from one day to another, without changes...

Reported by gerd.guehne.ecg.leipzig on 2013-06-20 12:10:12

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

I suspect the effective permissions display has some bugs.

I identified some errors in the determination of the effective permission earlier this
year which are fixed on master... however... the actual controls: canPush, canCreate,
canDelete, etc were unaffected by these errors.

A sample users.conf would be helpful.

Reported by James.Moger on 2013-06-20 12:20:46

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Thank you for your fast answer.

For this issue I attachted an user.conf that I have reduced to 3 users and 2 groups.
I hope it helps.

Reported by gerd.guehne.ecg.leipzig on 2013-06-20 12:32:53


- _Attachment: [uwe-users.conf](https://storage.googleapis.com/google-code-attachments/gitblit/issue-259/comment-4/uwe-users.conf)_

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

I have not been able to reproduce your permissions failure with 1.2.1 nor with master.
 I wrote (and committed) additional unit tests to exercise several permutations of
building the permission structures, but everything tested fine with both 1.2.1 and
master.

I did not spend any time looking at the effective permissions display because that
does not control anything and it is known to be incomplete if considering all users/teams.

For now, you'll have to keep an eye on it and report back here if you experience push
failure again.  Perhaps there will be more clues if it reoccurs.

Reported by James.Moger on 2013-07-03 01:37:20

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Thank you. Ok, I observed it.

Reported by gerd.guehne.ecg.leipzig on 2013-07-09 07:55:43

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

The bug occurs again. I have create 3 repositories in gitblit under a existing folder,
but user 'frostm' can't push to them. Clear cache are not help.

I found many many NPE's in logfile. Maybe this is the root cause?

INFO   | jvm 3    | 2013/07/11 16:48:35 | ERROR Failed to update team model git_1511!
INFO   | jvm 3    | 2013/07/11 16:48:35 | java.lang.NullPointerException
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.ConfigUserService.write(ConfigUserService.java:876)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.ConfigUserService.updateTeamModel(ConfigUserService.java:601)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.ConfigUserService.updateTeamModel(ConfigUserService.java:558)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.GitblitUserService.updateTeamModel(GitblitUserService.java:266)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.LdapUserService.authenticate(LdapUserService.java:209)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.GitBlit.authenticate(GitBlit.java:557)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.GitBlit.authenticate(GitBlit.java:669)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.AuthenticationFilter.getUser(AuthenticationFilter.java:101)
INFO   | jvm 3    | 2013/07/11 16:48:35 |       at com.gitblit.AccessRestrictionFilter.doFilter(AccessRestrictionFilter.java:139)
--------------------
INFO   | jvm 3    | 2013/07/11 16:49:48 | ERROR Failed to update team model git_EcgUser!
INFO   | jvm 3    | 2013/07/11 16:49:48 | java.lang.NullPointerException
INFO   | jvm 3    | 2013/07/11 16:49:48 |       at com.gitblit.ConfigUserService.write(ConfigUserService.java:876)
--------------------
INFO   | jvm 3    | 2013/07/11 16:48:55 | ERROR Failed to update user model langes!
INFO   | jvm 3    | 2013/07/11 16:48:55 | java.lang.NullPointerException
INFO   | jvm 3    | 2013/07/11 16:48:55 |       at com.gitblit.ConfigUserService.write(ConfigUserService.java:876)
---------------------
INFO   | jvm 3    | 2013/07/11 16:56:47 | ERROR Failed to update user model frostm!
INFO   | jvm 3    | 2013/07/11 16:56:47 | java.lang.NullPointerException
INFO   | jvm 3    | 2013/07/11 16:56:47 |       at com.gitblit.ConfigUserService.write(ConfigUserService.java:876)
---------------------

I look in the logfile, because I can't open the user group 'git_1530'. Only the error
message "internal error" is displayed in empty site. More details in error message
are helpful...


Reported by gerd.guehne.ecg.leipzig on 2013-07-11 15:33:32

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Before this I have renamed the new empty git repository. A error message is displayed:
Failed to rename repository permissions 'mts.portal/theme/ecg.standard.git' to 'mts.portal/theme/mts.portal.liferay.theme.ecg.standard.git'.

But after clear cache the new repository with new name is shown.
This is maybe the reason for NPE's in logfile and missing clone&push permissions?
I know yet it's dangerous to rename a git repository.

more wrapper.log | grep ecg.standard
INFO   | jvm 3    | 2013/07/11 16:55:58 | WARN  user frostm is not authorized to clone
mts.portal/theme/mts.portal.liferay.theme.ecg.standard

Reported by gerd.guehne.ecg.leipzig on 2013-07-11 15:40:43

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

I think I found it.

The key was the combination of knowing you use team permissions, the repository rename,
and the stacktrace snippets.

If the repo is renamed, the user and team permissions need to be updated.  If the user
inherits a permission by being a team member, the permission can't really be renamed
on the user - only on the team.  But Gitblit is trying to rename the nonexistent repository
permission on the user and introducing a null permission on the user account which
breaks persistence and also breaks runtime permission determination.

This is now fixed on master.

BTW, reset cache only resets the list of cached repositories.  It has nothing to do
with permissions which are stored in users.conf.

Reported by James.Moger on 2013-07-13 16:29:51

  • Status changed: Queued
  • Labels added: Milestone-1.3.0

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

Fix or enhancement released in v1.3.0

Reported by James.Moger on 2013-07-14 16:52:58

  • Status changed: Fixed

@gitblit
Copy link
Collaborator Author

gitblit commented Aug 12, 2015

great work, thank's!

Reported by gerd.guehne.ecg.leipzig on 2013-07-15 07:23:51

@gitblit gitblit closed this as completed Aug 12, 2015
@flaix flaix modified the milestone: 1.3.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