During installation process described here, the script asks for sudo powers to perform a chown command over the project files.
I don't feel confortable giving sudo powers to a script downloaded directly from Internet without being signed and confirmed its integrity. (Please, don't misunderstand me here. I'm not saying I don't trust Laravel or people behind Laravel. I'm just saying that someone unauthorized could modify that script or other kind of security issue).
I found out a workaround in order to avoid the sudo call. I'm not a docker expert so maybe this is not a good solution (or a good practice). Please, let me know it.
The idea is retrieving the host user's id (the user which is running the script) and create a user in the docker container with the same user id. This will allow us to change project files ownership during the install process in the container. Therefore, no sudo chown is required afterwards.
The following script is a modified version of the script downloaded from https://laravel.build/example-app with the changes exaplained above.
I've tested it in a Linux environment. Maybe it works in MacOS without any change. But not sure about Windows.
docker info > /dev/null 2>&1
# Ensure that Docker is running...
if [ $? -ne 0 ]; then
echo "Docker is not running."
exit 1
fi
project_name="example-app"
install_command="useradd -u ${UID} -s /usr/bin/bash ${USER}; laravel new ${project_name}; chown -R ${USER}: ./${project_name}"
docker run --rm \
-v $(pwd):/opt \
-w /opt \
laravelsail/php80-composer:latest \
/bin/bash -c "${install_command}"
cd ${project_name}
sed -i.bak 's/DB_HOST=127.0.0.1/DB_HOST=mysql/g' .env
sed -i.bak 's/DB_HOST=127.0.0.1/DB_HOST=mysql/g' .env.example
sed -i.bak 's/MEMCACHED_HOST=127.0.0.1/MEMCACHED_HOST=memcached/g' .env
sed -i.bak 's/MEMCACHED_HOST=127.0.0.1/MEMCACHED_HOST=memcached/g' .env.example
sed -i.bak 's/REDIS_HOST=127.0.0.1/REDIS_HOST=redis/g' .env
sed -i.bak 's/REDIS_HOST=127.0.0.1/REDIS_HOST=redis/g' .env.example
Notice: In the example above, I didn't want to make a lot of changes. That's why laravel new is not being executed by the user created recently in the container. However, we can improve the script calling laravel new with the user created which would generate the files with the right permissions directly and chown wouldn't be required afterwards (however, it will require some container changes like giving write permissions to user over /opt).
This is a draft. Some checks are missing (for example: if the user which is running the script has 0 as user's id. In this case, new user must not be created).
During installation process described here, the script asks for
sudo
powers to perform achown
command over the project files.I don't feel confortable giving
sudo
powers to a script downloaded directly from Internet without being signed and confirmed its integrity. (Please, don't misunderstand me here. I'm not saying I don't trust Laravel or people behind Laravel. I'm just saying that someone unauthorized could modify that script or other kind of security issue).I found out a workaround in order to avoid the
sudo
call. I'm not a docker expert so maybe this is not a good solution (or a good practice). Please, let me know it. The idea is retrieving the host user'sid
(the user which is running the script) and create a user in the docker container with the same user id. This will allow us to change project files ownership during the install process in the container. Therefore, nosudo chown
is required afterwards.The following script is a modified version of the script downloaded from
https://laravel.build/example-app
with the changes exaplained above.I've tested it in a Linux environment. Maybe it works in MacOS without any change. But not sure about Windows.
Notice: In the example above, I didn't want to make a lot of changes. That's why
laravel new
is not being executed by the user created recently in the container. However, we can improve the script callinglaravel new
with the user created which would generate the files with the right permissions directly andchown
wouldn't be required afterwards (however, it will require some container changes like giving write permissions to user over/opt
).This is a draft. Some checks are missing (for example: if the user which is running the script has
0
as user's id. In this case, new user must not be created).What do you think about it?