14

I would like to make .sh file for automatic deploy web pages from github to production. I need to run composer install in it but as I run it, it throws me a warning:

"Do not run composer install as root super user!"

I found out this is because of security reasons. But I need to run also other commands which needs to e.g. delete some files and directories.

The solution I found to fix this is:

composer install --no-scripts --no-interaction

The question is: Is it enough? Is --no-script the solution or not? What is the best practice regarding running composer as root?

yivi
  • 42,438
  • 18
  • 116
  • 138
Čamo
  • 3,863
  • 13
  • 62
  • 114
  • 1
    Best practice is to use sudo only for commands that require them https://serverfault.com/questions/507807/the-opposite-of-su-run-a-command-without-root-privileges – Martheen Jan 27 '21 at 10:28
  • 1
    Best solution is: don't run composer as root or sudo... You can run the other commands as su – Gert B. Jan 27 '21 at 10:29
  • I don't get your question - why not simply run composer with any other user? – Nico Haase Jan 27 '21 at 11:00
  • The the answer why I dont run composer as other user is because I would like to run a bunch of commands as .sh file and dont want to run it in interactive mode which will require passwords or other interaction. – Čamo Jan 27 '21 at 11:02
  • What keeps you from running these commands? Why do you need to trigger them through Composer? Also, why not run all scripts with the permissions needed in the first place? – Nico Haase Jan 27 '21 at 12:18
  • I want to make .sh file for deploy. It starts with git pull; composer install, npm install; .... – Čamo Jan 27 '21 at 12:19

3 Answers3

10

Best practice is not to use sudo for composer commands at all. If you need sudo for composer, it usually points at your project's file permissions not being setup correctly.

E.g. you should have a non-root user owning the projects directory, and you should run the needed commands as that user, without requiring sudo. If you need to run as root, it probably means that you did so in one of your previous runs, and already messed up your file permissions.

(Best practice is also not running install in production in any case, but at least you are not running update)

In the rarer cases where you need to run composer as a superuser, and you are not on a very constrained environment (say, building a Docker image), you should pay attention to the official guidance and not only use --no-scripts, but also the parameter --no-plugins, so you are only doing file copying and not executing other scripts.

yivi
  • 42,438
  • 18
  • 116
  • 138
  • Can you tell me which level of privileges is needed for the directory with project? Or is it better to set the same owner and privileges for whole /var/www folder? Another solution I found was to create temp user to run composer install but dont know the privileges of this temp user. – Čamo Jan 27 '21 at 11:20
  • 1
    Nothing special. Generally, you'll have a user that's distinct from `www-data` with read-write permissions on that directory. You can use the same for `/var/www`, if all the projects are yours and there is no other complications. It can simply whatever user you have at hand, and give that user ownership over those directories and subdirectories. It's a too broad a subject to broach here, but google on "linux file permissions php project" and similar things and you'll find a ton of material. – yivi Jan 27 '21 at 11:26
  • Yes tons of materials is the problem. I am lost in it. Last question, if I have user which differs from www-data and with read/write priv. am I able to run chown www-data:www-data ./dirPath without any complications? – Čamo Jan 27 '21 at 11:32
  • 1
    You generally shouldn't execute `chown www-data`. You should only need to do this in any directory where the server needs to write (e.g. to handle uploads). No other directory should belong to `www-data`. – yivi Jan 27 '21 at 11:36
  • Apache does not need to have -x priv to index.php? Who executes this script? – Čamo Jan 27 '21 at 12:05
  • 1
    No, they need only to be readable by the www process, that's all. The PHP interpreter reads and executes the file. This is getting a bit out of scope for the original question, isn't it? – yivi Jan 27 '21 at 12:08
1

Run as a user who has privileges to delete the "files and folders" you're talking about. If such a user does not exist, create one, assign ownership/privileges and then run composer under that user.
Simply running it as root just to delete a handful of known folders is a weak argument.

CodeWalker
  • 2,281
  • 4
  • 23
  • 50
1

I do not know the security implication of the following code but it seems to stop the issue; at least it removes the notice. I could be dangerous and if so please let it be noted in the comment or the answer be edited by anyone having the authority:

export COMPOSER_ALLOW_SUPERUSER=1; composer show;
Ajowi
  • 449
  • 3
  • 12