Bug/issue with assigning user permissions for Virtual Graphs


I am experiencing the following issue while assigning user permissions related to Virtual Graphs:


As you can see from the attached image, I assigned permission for creating Virtual Graphs to the user "userTest", so this user is able to create Virtual Graphs. However, the user is not able to read the mappings when trying to access the Foursquare Virtual Graph from Stardog Studio (which is created by this user, although the user has Read permission to this particular Virtual Graph), as you can see from the image below:

I tried the following thing, I gave Read permission to the user on the "Resource Type": "virtual-graph"; "Resource Name": " * ", as illustrated in the following image:


In this case, the user is able to access the mappings and change them.

But setting the Read permission to the user for any virtual graph, i.e. "Resource Name": " * ", allows him to see all Virtual Graphs, created by other users and see their mappings, which is not what we want.

An additional issue is that, Virtual Graphs can be queried by every user that knows the Virtual Graph name, even without having specific permissions.

Thank you in advance.

For which user is that list of permissions?

I see that this user has read permission for the user\userTest resource, but I don't see that the screen is displaying the permissions for the userTest user.


For the same user: "userTest", see below:


OK, thanks for checking that.

Please check two more things:
a) Was the VG actually created (or is this a permissions issue)? To check this, change back to user admin and see if the VG is there.
b) Is there any error in the stardog.log file?


You're welcome.

a) yes, the Virtual Graph is created. But the user is not able to read the mappings, when the permissions are according to the very first figure.
a.1) When the permissions are as in the third figure (with READ enabled on "Resource Name": " * "), the user is able to read the mappings. The problem here is that, the user is also able to see the mappings for Virtual Graphs created by others.

b) here is the log for the a) case:

ERROR 2019-05-15 14:02:56,866 [stardog-user-32] com.complexible.stardog.protocols.http.server.StardogHttpServiceLoader:accept(235): An unexpected exception was handled by the server
com.complexible.stardog.security.StardogAuthorizationException: Permission [[read], [virtual-graph], [virtual://foursquare]] denied for userTest
at com.complexible.stardog.security.ShiroUtils.require(ShiroUtils.java:193) ~[stardog-core-security-6.1.3.jar:?]
at com.complexible.stardog.security.ShiroUtils.require(ShiroUtils.java:175) ~[stardog-core-security-6.1.3.jar:?]
at com.complexible.stardog.virtual.SecuredVirtualGraphRegistry.assertVirtualGraphRead(SecuredVirtualGraphRegistry.java:233) ~[stardog-virtual-core-6.1.3.jar:?]
at com.complexible.stardog.virtual.SecuredVirtualGraphRegistry.getOptions(SecuredVirtualGraphRegistry.java:94) ~[stardog-virtual-core-6.1.3.jar:?]
at com.complexible.stardog.virtual.GetMappingsUtil.getMappings(GetMappingsUtil.java:46) ~[stardog-virtual-core-6.1.3.jar:?]
at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.getMappingsForSyntax(VirtualGraphHttpService.java:301) ~[stardog-virtual-protocols-http-server-6.1.3.jar:?]
at com.complexible.stardog.protocols.http.server.virtual.admin.VirtualGraphHttpService.getMappingsForSyntax(VirtualGraphHttpService.java:293) ~[stardog-virtual-protocols-http-server-6.1.3.jar:?]
at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-6.1.3.jar:?]
at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.2.3.jar:1.2.3]
at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.2.3.jar:1.2.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_212]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]

Thanks for all that. I'm able to reproduce a similar issue now, however when I do so I get a slightly different result. The particulars of what I can reproduce require that I request the mappings in the same format in which they were saved (SMS2 in my case, but that shouldn't matter). The bug is that it checks for permissions on the foursquare resource rather than the virtual://foursquare resource. Doing so leads to this error: Permission [[read], [virtual-graph], [foursquare]] denied for userTest. Your error is different, though: Permission [[read], [virtual-graph], [virtual://foursquare]] denied for userTest. In my case a workaround is to add permission for foursquare in addition to virtual://foursquare.

So, what I'm indicating should NOT fix your issue. Nonetheless, it might be worth a try. Can you try similar tests from the CLI app?
stardog-admin virtual mappings -u userTest -p password -f stardog foursquare
stardog-admin virtual mappings -u userTest -p password -f sms2 foursquare
And while we're at it:

stardog-admin user permission userTest
| Resource Type |    Resource Name     | Permissions | Source     |
| user          | userTest             | --R----     | [userTest] |
| virtual-graph | *                    | C------     | [userTest] |
| virtual-graph | foursquare           | --R----     | [userTest] |
| virtual-graph | virtual://foursquare | -DR----     | [userTest] |

What you find may help me diagnose. If you could provide the stardog.log for the different attempts that could help as well.


Thank you for your reply.

But when the user creates a new Virtual Graph, its name will in the form of '<'virtual://graphName'>', in this case '<'virtual://foursquare'>' ; and not only the graphName.

Following the way that you are suggesting, means that an administrator after each new graph should put another entry to the user permissions in the following form:

| virtual-graph | graphName | --R---- | [userName] |

This would be cumbersome for the admin.

P.s. I didn't try yet your suggestion, just wanted to be clear before doing that, since I myself don't have admin permissions to the Stardog instance.

Understood. I'm only suggesting this as a way to test this situation and as a temporary work around until a fix becomes available.


Right, thank you very much.

So, basically, we will wait for a fix. We can live with that for now.


Please confirm that the work around did indeed work once you've had a chance to test it. I'm worried that the bug I found is not the same as your issue.


Ok, I will try to replicate your workaround. Unfortunately, I can only do that in the course of the next week, since my colleague with admin permissions is away till next week.

Once I am done, will add the results here.


1 Like