2016-05-05 13:22 GMT+02:00 Chetan Mehrotra <[email protected]>:
> On Thu, May 5, 2016 at 4:38 PM, Francesco Mari <[email protected]> > wrote: > > > The security concern is quite easy to explain: it's a bypass of our > > security model. Imagine that, using a session with the appropriate > > privileges, a user accesses a Blob and adapts it to a file handle, an S3 > > bucket or a URL. This code passes this reference to another piece of code > > that modifies the data directly even if - in the same deployment - it > > shouldn't be able to access the Blob instance to begin with. > > > > How is this different from the case where a code obtains a Node via an > admin session and passes that Node instance to another code which say > deletes important content via it. In the end we have to trust the client > code to do correct thing when given appropriate rights. So in current > proposal the code can only adapt the binary if the session has expected > permissions. Post that we need to trust the code to behave properly. > This is a totally different thing. The change to the node will be committed with the privileges of the session that retrieved the node. If the session doesn't have enough privileges to delete that node, the node will be deleted, There is no escape from the security model. > > > In both the use case, the customer is coupling the data with the most > > appropriate storage solution for his business case. In this case, > customer > > code - and not Oak - should be responsible for the management of that > data. > > Well then it means that customer implements its very own DataStore like > solution and all the application code do not make use of JCR Binary and > instead use another service to resolve the references. This would greatly > reduce the usefulness of JCR for asset heavy application which use JCR to > manage binary content along with its metadata > What I said doesn't reduce the usefulness of JCR. JCR defines an abstraction that is independent from the actual storage solution. If a client is fine with using the abstraction, JCR can be a very useful tool. If a client needs to escape the abstraction, he has to do it at his own risk without breaking the abstraction for everyone else. In the outlined use cases, the customer needs to be responsible for his own storage mechanisms. > > > Chetan Mehrotra >
