Disallowing writes to default graph

We're trying to set up a database so that users can write only to specific named graphs, not the default graph. We're not having much luck.

With permissions like this:

+---------------+-------------------+-------------+
| Resource Type |   Resource Name   | Permissions |
+---------------+-------------------+-------------+
| db            | SBAR-593          | --R----     |
| metadata      | SBAR-593          | ---W---     |
| named-graph   | messages          | --RW---     |
+---------------+-------------------+-------------+

Trying to insert something:

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX ns: <http://SBAR-593/ns#>

INSERT DATA
{ GRAPH ns:messages { <http://SBAR-593/message2> ns:title "The Hitchhiker's Guide to the Galaxy" }} 

Fails with "User does not have write permissions for the index. User identification "SBAR-593"; index name "SBAR-593". Giving the user write on SBAR-593 will make the insert succeed, but this is not what we want.

Can we not prevent writes to the default graph while only granting them on specific named graphs?

Just FYI, I've also opened this as a support case with Stardog after posting here. I'll post the solution as well once there is one (it could be that we misunderstood the security model).

Sounds like you want named graph security.

You could grant write access to only specific named graphs or to tag:stardog:api:context:named which includes everything but the default graph (tag:stardog:api:context:default).

-Paul

Thanks, we do have named graph security enabled but I was told security.named.graphs.empty.allows.access needs to be disabled for this to prevent writes to the default graph. I might be able to try this today and I can report if it works in this constellation.

The trick is indeed:

  • security.named.graphs.empty.allows.access needs to be false
  • The user needs write permission on the database and any relevant named graphs

This way, writes to the default graph will be rejected. It seems security.named.graphs.empty.allows.access is an undocumented option, I think it would be good to document it so this behavior becomes clearer.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.