In relational database, default permissions are trivial. DBA is usually the only account that can access any table for both read and write. Making some table public or private does not affect applications that do not refer that table in the code. Tables are always created before making security restrictions on them.

Chances are very low that an application will unintentionally create some table and fill in with confidential data. There are no unauthenticated users, any client has some user ID and no one user is "default user" so permissions of any two users are always independent.

SPARQL access can be anonymous and graphs can be created during routine data manipulation. For anonymous user, only public resources are available. Thus "default permissions" on some or all graphs are actually permissions of "nobody" user, (the numeric ID of this user can be obtained by http_nobody_uid() function call). As a consequence, there's a strong need in "default permission" for a user, this is the only way to specify what to do with all graphs that does not exist now it might exist in some future.

An attempt to make default permissions wider than specific is always potential security hole in SPARQL, so this is strictly prohibited.

Four sorts of access are specified by four bits of an integer "permission bit-mask", plain old UNIX style:

Note that obtaining the list of members of a graph group does not grant any access permissions to triples from member graphs. It is quite safe to mix secure and public graphs in one graph group.

When a SPARQL query should check whether a given user have permission to access a given graph then the order of checks is as follows:

If no one above mentioned permission is set then the access is "read/write/sponge/list".

For "nobody" user, steps 3 and 4 become exact copies of steps 1 and 2 so they are skipped.