Open aknosis opened 1 year ago
Thank you for the detailed report and investigation!
Maybe a simple fix could be to chmod 777 the storage dir? Any downside?
Is this only an issue on the dev images, or on all fpm images?
oh good point!
I tested in Lambda with php-82-fpm
and it seems that everything is run under sbx_user1051
. This means that the initial bref startup and the fpm user are both the same so this won't be an issue in Lambda.
Startup logs:
INIT_START Runtime Version: provided:al2.v17 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:f35635a04216ba4e6a0e74d3c2db080d443709a8f3f2e71fedf54a4f8756705d
Creating storage directories: /tmp/storage/bootstrap/cache, /tmp/storage/framework/cache, /tmp/storage/framework/views, /tmp/storage/psysh
NOTICE: [pool default] 'user' directive is ignored when FPM is not running as root
Output of ls -alR /tmp
:
/tmp:
total 16
drwx------ 4 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 1 root root 4096 Nov 3 2022 ..
drwxrwxr-x 2 sbx_user1051 990 4096 May 8 17:04 .bref
drwxr-xr-x 5 sbx_user1051 990 4096 May 8 17:04 storage
/tmp/.bref:
total 12
drwxrwxr-x 2 sbx_user1051 990 4096 May 8 17:04 .
drwx------ 4 sbx_user1051 990 4096 May 8 17:04 ..
-rw-r--r-- 1 sbx_user1051 990 2 May 8 17:04 php-fpm.pid
srw-rw---- 1 sbx_user1051 990 0 May 8 17:04 php-fpm.sock
/tmp/storage:
total 20
drwxr-xr-x 5 sbx_user1051 990 4096 May 8 17:04 .
drwx------ 4 sbx_user1051 990 4096 May 8 17:04 ..
drwxr-xr-x 3 sbx_user1051 990 4096 May 8 17:04 bootstrap
drwxr-xr-x 4 sbx_user1051 990 4096 May 8 17:04 framework
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 psysh
/tmp/storage/bootstrap:
total 12
drwxr-xr-x 3 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 5 sbx_user1051 990 4096 May 8 17:04 ..
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 cache
/tmp/storage/bootstrap/cache:
total 8
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 3 sbx_user1051 990 4096 May 8 17:04 ..
/tmp/storage/framework:
total 16
drwxr-xr-x 4 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 5 sbx_user1051 990 4096 May 8 17:04 ..
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 cache
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 views
/tmp/storage/framework/cache:
total 8
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 4 sbx_user1051 990 4096 May 8 17:04 ..
/tmp/storage/framework/views:
total 8
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 4 sbx_user1051 990 4096 May 8 17:04 ..
/tmp/storage/psysh:
total 8
drwxr-xr-x 2 sbx_user1051 990 4096 May 8 17:04 .
drwxr-xr-x 5 sbx_user1051 990 4096 May 8 17:04 ..
777
perms on storage will work, but I am curious why are we assigning the user to nobody
?
but I am curious why are we assigning the user to nobody?
IIRC this is because when running in Docker, things run as root
and FPM doesn't like running as root.
Maybe a simple fix could be to chmod 777 the storage dir? Any downside?
I'm fine with this, I don't foresee any negative impact in the dev image or in Lambda
When storage directories are created for the first time they get created as
root:root
(due to being executed by bref hooks).The issue is that web requests cannot write to the storage directory because fpm runs under the nobody user and you end up with errors like below.
If I delete
/tmp/storage
after initial creation and fire a web request, it will happily create the storage directories asnobody:nobody
.Curious on thoughts of how to solve this.