No I like that approach In a system we're building currently in $dayjob we do much the same thing. If a user doesn't have permission to see the data it just looks to that user like that data does not exist so they get null, empty/truncated lists, false etc. From an information security perspective soft errors are actually more secure because they don't provide side channels. With a hard error users can explicitly distinguish between data that isn't there and data that is there but to which they don’t have access i.e. a clever user can infer the existence of data under a hard error setup. With soft errors the two cases are indistinguishable.
Jena 4 is an opportunity to make breaking changes so even if you make the soft vs hard error behaviour configurable I would suggest making the default be soft error and document the change as part of whatever Jena 3 -> 4 migration guide we end up writing. Then people who are using the permissions modules and upgrading would be forced to understand the change, the reasoning behind it and make a decision about how to migrate based on their own use cases. If you leave the default as-is those users could carry on none the wiser without realising they are missing out on potential security benefits. Rob On 01/03/2021, 22:44, "Claude Warren" <[email protected]> wrote: I started looking at the read permissions on graphs issue that was raised today. It seems to me that if we change the functioning of graph.find() then we need to change graph.contains() and graph.size() accordingly. 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. 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. 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? Claude -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
