In Clerezza the graph check for read-permission on read and
readwrite-permission on add and delete. As the name suggests readwrite
permission implies read permission.

The reason for that is that the add-method returns false is a triple was
already in the graph so even a pure write permission would leak information
on what's in the graph.

I think security should be done with standard jaas and is independent of
particular interfaces in the api.

Cheers,
Reto
On Nov 16, 2012 2:45 PM, "Claude Warren" <[email protected]> wrote:

> >> Immutable Graphs: I had really problems to get this right and the
> >> current Clerezza API does not help with that task (resulting in things
> >> like read-only mutable graphs that are no Graphs as they only provide
> >> a read-only view on a Graph that might still be changed by other
> >> means). I think read-only Graphs (like
> >> Collections.unmodifiableCollection(..)) should be sufficient. IMHO the
> >> use case to protect a returned graph from modifications by the caller
> >> of the method is much more prominent as truly immutable graphs.
>
> I am currently working on a set of dynamic proxies in an attempt to
> add security all all layers of the Jena stack.  I currently have the
> graph layer complete and the model layer 50% done.
>
> My thought is that in addition to having read only you might want to
> have write only (I know that sounds strange but I've seen such in
> DBs).  The upshot is that I would put full CRUD restriction
> capabilities within the system.
>
> I'm not sure that it will work but I thought I would give it a try.  I
> think that something needs to be done in this arena to go along with
> the Fuseki security discussion I saw awhile back.
>
> Claude
>

Reply via email to