Hi, Dont forget. Unless the JVM is running a JVM security manager, any attempts to enforce security implemented in Java even in an OSGi environment will be futile once malicious byte code is loaded. I won't share how, but it's obvious when you start to think maliciously, especially if you can trigger a container restart.
Which is why I suggested that if the API is introduced it should create an out of band agreement with the consumers of the API to act responsibly. I remain +1 (non binding) on the API. Best Regards Ian On 5 May 2016 at 12:37, Francesco Mari <mari.france...@gmail.com> wrote: > 2016-05-05 13:22 GMT+02:00 Chetan Mehrotra <chetan.mehro...@gmail.com>: > > > 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. > > > > 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 > > >
