Context: This came up in the discussion on JENA-2055.
There are two scenarios for permissions control: request denial and
triple hiding.
In denial mode, an operation may throw an exception. This is what
current jena-permission does. It works well for "read vs write" access
control.
In hiding mode, the graph operations do not throw exceptions, but they
show a view of the data based on what allowed to be accessed. Triples
the request can't access simply aren't there. contains(s,p,o) returns
false. It is "read, "no read" access control.
See jena-fuseki-access for hiding mode based on access control on
graphs. It is read-centric because update risk revealing whether triples
are in the total graph or not.
On 01/03/2021 22:44, Claude Warren wrote:
I started looking at the read permissions on graphs issue that was raised
today.
SecuredGraph
It seems to me that if we change the functioning of graph.find() then we
need to change graph.contains() and graph.size() accordingly.
graph.contains(s,p,o) = graph.find(s,p,o).hasNext()
graph.size() = count(graph.find(?,?,?))
This led me to look at the Model based classes, and there we find a number
of iterators, lists of properties, hasX() methods, etc. All of which
currently throw the ReadDeniedException.
SecuredModel
Changing these methods will change the default operation in the wild.
Something that is OK for v4 but in v3 I think it should stay the same.
So I am thinking that it might make sense to specify HardReadErrors (the
current throw the exception we have now) or SoftReadErrors (return empty
iterators, false for hasX() and so on). At first I thought of putting this
in a context, but it could be added to the SecurityEvaluator. Since the
SecurityEvaluator is an interface I would add it with a default of
HardReadErrors and allow implementations to override that.
There are two interfaces: SecuredGraph (operation denial, exception
throwing) and the normal Graph. Ditto SecuredModel and Model.
I don't see the SecuredGraph interface needing to change (they are
runtime exceptions). Am I missing something?
In order to avoid information leaks, mixing modes looks "complicated"
(i.e. dangerous).
Implementing a read-only, data visibility graph is quite easy - it's
find+filter.
Graph g = new GraphBase() {
@Override
protected ExtendedIterator<Triple>
graphBaseFind(Triple triplePattern) {
other.find().filterKeep ...
}};
The rest just follows.
Other operations doing better than this are nice to have.
I think this might be the best way forward, though there will be a lot of
change in the permissions code base. Does anyone see an issue with this
approach or a better approach?
With information hiding, the query case on JENA-2055 works. No mid-query
execution exceptions.
Andy
Claude
