@derrickpeavy uauuu… that was a tough one!!! Glad you solved it! Thanks for sharing all your code, screenshots and your solution. This was/is a super interresting and valuable post to read and follow. @carehart blog post is also super interesting one. Thanks for the tip.
I wonder if Julian_Halliwell is correct abut the issue from 5.3.4 onward. And I say that because this code I have had problems with is not new. Most of it has been used for more than a decade in one form or another. And the present iteration was written and implemented in 2019 and it worked no problem, regardless of the permissions. So, I think he is on to something. It may not be an official “bug” and maybe it’s even intentional, but I don’t think it is “expected.”
I filed the bug as a “regression” because it definitely changed previously predictable behaviour: which was that an uploaded file would inherit the permissions of its
destination directory. Now the file only has the permissions assigned to the temp directory (which are likely to be restrictive).
I’m almost certain it wasn’t intentional, but as I implied in the blog, I’m not sure that the previous behaviour is best from a security standpoint. Uploaded files shouldn’t be given public access permissions until they’ve been checked. Which means automatic assignment of permissions is a bit risky.
Being forced to use
FileSetAccessMode() or my Windows alternative to set them manually after checking is arguably a safer workflow. It’s what we do by default for all uploads now.
My take on technology is, “there is no wrong way to eat a reese’s”.
Where name is either tomcat, or www-data depending on which group you decide needs to be the owner of the data
remove -R for recursion.
setfacl -Rdm group:name:rwx /path/to/user-receipts/
r = read
w = write
x = execute
which stands why even though you do not have 755 permissions on something, it still executes… its UBUNTU(ism).
Can you expand on this? From what I found by using FileSetAccessMode(), I can set the owner to www-data as well as the group. Or, keep one as Tomcat. But it is easier to just keep everything www-data.
But if I understand the setfacl command, you are saying that by running it, I will be giving Tomcat full permission to that directory, regardless of mode?
The way I fix and or think of systems, be it Windows, NIX or other, its just the vehicle to getting what you need done, completed.
I am not saying checking or implicitly setting file permissions is bad from an application. I think its great that ability is there, but I guarantee the OS is far more efficient at doing it than the application, and not just Lucee, but any application.
That is why when you posted above it was like, Oh its a permissions issue. Sure the application can be set to constantly fix the OS, however I’m a pragmatic.
I want the OS to do what it does best, which is deliver the application.
I want the application to do what it does best, which is do whatever it was designed to do.
As for Ubuntu:
Ubuntu literally is one distro I avoid as much as possible on a personal level as it doesn’t adhere to any kind of standard *NIX rules. Its popular for good reason. The graphics are nice, the support is fair, but for me its as piggy as Windows and just as quirky, if not worse in some respects IMHO. Ubuntu is based upon debian’s beta, which often leads to bugs.
At the end of the day, I just want something to work, and I do not care if its running a slightly older version of some software package.
Anyrate, back to the topic
setfacl is for discretionary control to files or folders, when UGM (user group mode) is not enough.
that being said, its not widely adopted, again IMHO.
its used in conjunction with "getfacl’
You would use getfacl as
I am sure if you did a man getfacl or setacl you should get the flag options and description of how its used.
the man page for ubuntu’s version of setacl is here