On Thu, May 5, 2016 at 4:38 PM, Francesco Mari <mari.france...@gmail.com> 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. > 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 Chetan Mehrotra
