[
https://issues.apache.org/jira/browse/OAK-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16528471#comment-16528471
]
Alexander Klimetschek edited comment on OAK-7570 at 6/30/18 1:12 AM:
---------------------------------------------------------------------
[~mduerig]
> SegmentNodeStore is conceptually not a HttpBlobProvider
Every NodeStore is a "BlobProvider" (if that interface would exist, referring
to the createBlob()/getBlob() methods on NodeStore).
I feel the argument here is touching on an existing design of Oak - nothing new
this patch changes. If NodeStores should not be blob providers, then the
BlobStore should be something known to the higher level (e.g. Tree/Root). And
if there is no separate BlobStore (i.e. a file or S3 DS), but everything is
handled by the NodeStore itself, the BlobStore instance would be provided by
the NodeStore impl itself during the setup.
> permission check
I think this opens a door for anonymous users to fill up the S3/Azure datastore
and create denial-of-service load on e.g. the DS garbage collection. It's also
easier for an attacker – compared to creating a binary from an inputstream –
since they don't need to upload a binary to AEM in the first place. See also my
mail to the private jackrabbit list.
> Nothing seem to prevent users to later attach the binary to any other
> property.
Yes, but that is actually no problem. There will be another check later (the
normal one). We only want to prevent a user who cannot write a binary
_anywhere_ from being able to upload in the first place (e.g. anonymous). There
is no other way to check that permission than to ask for the path - at least as
far as we know. Recommendations welcome.
> separating read and write concerns
I argue that intuitiveness for client code is more important here, as well as
saving on new API interfaces (which we already have more than enough if I
understand the feedback right ;-)). Because that would be 3 new interfaces,
HttpBinary, HttpBlob and HttpDataRecord.
was (Author: alexander.klimetschek):
[~mduerig]
> SegmentNodeStore is conceptually not a HttpBlobProvider
Every NodeStore is a "BlobProvider" (if that interface would exist, referring
to the createBlob()/getBlob() methods on NodeStore).
I feel the argument here is touching on an existing design of Oak - nothing new
this patch changes. If NodeStores should not be blob providers, then the
BlobStore should be something known to the higher level (e.g. Tree/Root). And
if there is no separate BlobStore (i.e. a file or S3 DS), but everything is
handled by the NodeStore itself, the BlobStore instance would be provided by
the NodeStore impl itself during the setup.
> permission check
I think this opens a door for anonymous users to fill up the S3/Azure datastore
and create denial-of-service load on e.g. the DS garbage collection. It's also
easier for an attacker since they don't need to upload a binary to AEM in the
first place. See also my mail to the private jackrabbit list.
> Nothing seem to prevent users to later attach the binary to any other
> property.
Yes, but that is actually no problem. There will be another check later (the
normal one). We only want to prevent a user who cannot write a binary
_anywhere_ from being able to upload in the first place (e.g. anonymous). There
is no other way to check that permission than to ask for the path - at least as
far as we know. Recommendations welcome.
> separating read and write concerns
I argue that intuitiveness for client code is more important here, as well as
saving on new API interfaces (which we already have more than enough if I
understand the feedback right ;-)). Because that would be 3 new interfaces,
HttpBinary, HttpBlob and HttpDataRecord.
> [DirectBinaryAccess][DISCUSS] Client access via DataStoreBlobStore directly
> ---------------------------------------------------------------------------
>
> Key: OAK-7570
> URL: https://issues.apache.org/jira/browse/OAK-7570
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: blob-plugins
> 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)
