jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-7570) [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
Date Wed, 11 Jul 2018 17:14:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540398#comment-16540398
] 

Alexander Klimetschek edited comment on OAK-7570 at 7/11/18 5:13 PM:
---------------------------------------------------------------------

{quote}But the path parameter also doesn't add anything useful to the API. The current API
already allows a client to perform this check and then decide to proceed with requesting upload
URLs. In my view, combining them in a single call gives a false sense of security because
client code is free to use whatever path it wants.
{quote}

You are right, application code could do the check itself (session.hasPermission()). However,
as we know, that isn't really done in the case of binaries created from InputStream today
(but probably should be as well!). The general mantra with JCR is that it does access control
for you, so devs aren't really expecting to call {{session.hasPermission()}} et.al. in their
code.

And in this case here the developer will also think "I am not persisting the session here,
why should I make AC checks". Yes, it can be documented, but experience shows this is not
enough for a safe system. That's why I think it should be forced upon clients.

The point is, even if the client could use a different path, if they do not provide a path
they have write access to, they will get an immediate AccessDeniedException. This is not possible
without a path argument (today, without I assume bigger changes to Oaks permission model).
I feel uncomfortable taking this important security check out until there is a clear plan
for a better alternative with the same protection.

Having the client to provide the path in the API, but not leveraging it in the implementation
(in the future) seems not a problem to me.


was (Author: alexander.klimetschek):
{quote}But the path parameter also doesn't add anything useful to the API. The current API
already allows a client to perform this check and then decide to proceed with requesting upload
URLs. In my view, combining them in a single call gives a false sense of security because
client code is free to use whatever path it wants.
{quote}

You are right, application code could do the check itself (session.hasPermission()). However,
as we know, that isn't really done in the case of binaries created from InputStream today.
After all, the developer will think "I am not persisting the session here". Yes, it can be
documented, but experience shows this is not enough for a safe system. That's why I think
it should be forced upon clients.

The point is, even if the client could use a different path, if they do not provide a path
they have write access to, they will get an immediate AccessDeniedException. This is not possible
without a path argument (today, without I assume bigger changes to Oaks permission model).
I feel uncomfortable taking this important security check out until there is a clear plan
for a better alternative with the same protection.

Having the client to provide the path in the API, but not leveraging it in the implementation
(in the future) seems not a problem to me.

> [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
> -------------------------------------------------------------------------
>
>                 Key: OAK-7570
>                 URL: https://issues.apache.org/jira/browse/OAK-7570
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: jcr
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
>
> Open discussion related to OAK-7569:
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88] proposes
changes to oak-api, oak-segment-tar, oak-store-document, oak-core, and oak-jcr as well as
oak-blob-plugins, oak-blob-cloud, and oak-blob-azure.  Would it be possible / better to keep
the changes local to the oak-blob-* bundles and avoid making changes throughout the stack?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message