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

Deadlock when calling IsGranted from within Walk #21

Open
shmul opened this issue Feb 14, 2018 · 5 comments
Open

Deadlock when calling IsGranted from within Walk #21

shmul opened this issue Feb 14, 2018 · 5 comments

Comments

@shmul
Copy link

shmul commented Feb 14, 2018

Hi,

I wrote a simple function to test my use of the package and discovered that if one calls IsGranted from within the Walk handler function, the code hangs. Looking into the code it looks like a deadlock.
Would it be possible to expose a non locking version of IsGranted (basically the existing private isGranted).

Cheers,
Shmul

@mikespook
Copy link
Owner

Could you show me some more codes to help me understand the use case?
I'd like to modify the helper functions rather than RBAC API, but with the use case, we may figure out which way is the best one for us.

Thanks & cheers!

@ccamel
Copy link

ccamel commented Mar 20, 2019

@mikespook
I confirm that there is a possible deadlock when calling a RBAC function inside the Walk handler.
In go, rw mutex are not reentrant.

I don't have a very useful case, but here's a unit test which shows the issue.

func TestRBACDeadLock(t *testing.T) {
	// Arrange
	rbac := gorbac.New()
	rA := gorbac.NewStdRole("role-a")
	pA := gorbac.NewStdPermission("permission-a")
	rA.Assign(pA)
	rbac.Add(rA)

	// Act
	gorbac.Walk(rbac, func(role gorbac.Role, strings []string) error {
		// -> boom: deadlock!
		rbac.Add(gorbac.NewStdRole("role-b"))

		return nil
	})
}

@mikespook
Copy link
Owner

@ccamel Thx!

Yes, it's a known issue we have. I'm considering to expose the lock method and let users control the lock with helper functions. But I haven't found a solution which could be easy but safe to do so.

@ccamel
Copy link

ccamel commented Mar 21, 2019

@mikespook Thanks for your reply.

I for one don't really like the idea to expose the lock object to outside. I would prefer to have the callback function called in a context freed from any lock. It should be feasible but at the cost of a copy of the context before the call.

@mikespook
Copy link
Owner

Yes, I don't like it either. That's the reason I didn't change the API when I found the deadlock.
Another issue is, helper functions are not the core functions for the library, thus changing the main API to solve an issue in helper functions sounds not a practical way.

Exposing the lock-free functions would be the easiest way, but I'm wondering the effects to the helper functions when it's calling from a concurrent situation. Let's think about it. I will try to figure out all possibility use-case to see if it's good or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants