The upload feature with ACL kept "public-read" doesn't get uploaded into S3 bucket.

Commenting the below line in S3fsStreamWrapper.php, uploads the file in S3 bucket and makes it public.

if (!empty($this->config['use_cname']) && !empty($this->config['domain']) && !empty($this->config['domain_s3_private'])) {
$upload_params['ACL'] = 'private';
}
elseif (file_uri_scheme($this->uri) != 'private') {
//$upload_params['ACL'] = 'public-read'; // This line of code is commented
}

i think this line is adding issue.

Has anybody experienced this ?

CommentFileSizeAuthor
#12 2987225-12.patch755 bytesphma
#7 2987225-7.patch687 bytesl0ke

Comments

gouli created an issue. See original summary.

coredumperror’s picture

coredumperror commented

That's definitely not supposed to happen. And sure, maybe the file uploads, but it'll upload with the 'private' ACL, which means no one will be able to view it.

My guess is that something outside of S3FS's control is at fault here. I've seen issues with certain PHP optimizers that cause similarly baffling problems, so you might try disabling yours, if you have one, to see if that fixes the problem without commenting out that essential line of code.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

I'm seeing this on D8 - upload silently fails, but if I comment out the setting of public-read the upload succeeds but the file isn't readable.

What's interesting is that things work when I use an access/secret key with full access, but it fails with one where all Delete* operations are disabled. On Validate Configuration, the PutObject succeeds and DeleteObject fails.

Continuing to debug this...

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Well, I found my problem - the policy I was using did not include PutObjectAcl. Thus, when it attempts to set the public-read ACL on the object, the PutObjectAcl call fails and blows it all out - without setting the ACL, PutObjectAcl is not called so there's nothing to prevent PutObject from working.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

I was thinking it'd be nice to have some error-handling here - but, down at the bottom where this happens all we're getting is a 403 Forbidden - Access denied, with no info to suggest the problem is with PutObjectAcl rather than PutObject, so we can't get too specific.

I also note that you don't get any indication on the front end that anything's gone wrong, other than the lack of a thumbnail - the failure is not propagating up through move_uploaded_file(). But, I see there's already an issue for that: #2972161: File operations return successful even when they fail.

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Pittsfield, MA, USA
commented

Actually, S3fs can help here - the validator could, after the existing PutObject without an ACL, try one with an ACL - if only the second one fails, then you're missing the PutObjectACL permission.

l0ke’s picture

l0ke
Primary language English
Location Ukraine
commented
Version: 7.x-2.11 » 8.x-3.x-dev
StatusFileSize
new 2987225-7.patch687 bytes

Pretty same issue with the latest 8.x version.
We should check for upload_as_private setting. There is a correct condition in the stream_flush() method but not in rename()

l0ke’s picture

l0ke
Primary language English
Location Ukraine
commented
Status: Active » Needs review

  • cmlara committed 84b1ab9 on 8.x-3.x authored by l0ke 
    Issue #2987225 by l0ke: Public Read ACL key
cmlara’s picture

cmlara
he/him
commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

phma’s picture

phma commented
StatusFileSize
new 2987225-12.patch755 bytes

Backport of this fix for 7.x-2.x