Addressing the following ticket did raise some questions:
https://luceeserver.atlassian.net/browse/LDEV-1396
this ticket has 2 points:
- attribute “acl” is ignored
- default ACL is “public-read” instead of “private”
First one is fixed, that is not the issue, what i’m concern is to change the default ACL from “public-read” to “private”. Because this possible affect existing code, not an issue from a security perspective, but still an issue because we make the result of the S3 functionality more restrictive.
In my opinion we should not change the default behaviour within a patch, even ACF acts different in this case (what i did not test yet).
An idea to solve this is the possibility to add the following possibility to the Application.cfc.
this.s3.acl="private"; // sets the default ACL
sure you already can do the following today
this.tag.file.acl="private";
this.tag.directory.acl="private";
What do you think about this?
Should we change the ACL behaviour (in the next patch,minor,major release)?
What you think about the Application.cfc setting?
2 Likes
On CFDocs it says the 2nd argument to storeSetACL is required, as does the Lucee docs;
If that’s the case then in compatibility terms it might be less of a problem that Lucee has a default (regardless of the value) because it’s always required in ACF. I’ve had a quick look at our code and we always specify the ACL, because we have customers on both CFML engines.
However, as you say, changing the default value for Lucee could present some problems if the function was used differently to how it’s documented. I’m not sure how prevalent this “mistake” might be, but I think I’d be happy with a change to the default in a minor release, as long as we announce it and document the default 
It doesn’t seem like a high risk change, but happy to wait and hear others thoughts.
The Application.cfc setting on the s3 struct might be useful to some.
1 Like
I personally don’t mind default settings to be “public” with ability to change this behaviour via application settings.
By default, all Amazon S3 resources — buckets, objects, and related subresources (for example, lifecycle configuration and website configuration) — are private: only the resource owner, an AWS account that created it, can access the resource.
Sure it does not matter for this function but it matters when you do for example
<cffile action="write" file="s3://...." ...>
Use the s3 as a resource, in that case it matters when the default behavior does change.