“--no-scripts”选项是否足以解决以 root 身份运行 composer 的安全问题？答案

【问题标题】：Is the "--no-scripts" option enough to account for the security concerns about running composer as root?“--no-scripts”选项是否足以解决以 root 身份运行 composer 的安全问题？
【发布时间】：2021-10-31 17:46:27
【问题描述】：

我想制作.sh 文件，用于将网页从 github 自动部署到生产环境。我需要在其中运行 composer install 但是当我运行它时，它会向我抛出一个警告：

“不要以 root 超级用户身份运行 composer install！”

我发现这是出于安全原因。但我还需要运行其他需要的命令，例如删除一些文件和目录。

我找到的解决方法是：

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

问题是：够了吗？ --no-script 是解决方案吗？以 root 身份运行 composer 的最佳实践是什么？

【问题讨论】：

最佳实践是仅对需要它们的命令使用 sudo serverfault.com/questions/507807/…
最好的解决方案是：不要以root或sudo运行composer...你可以以su运行其他命令
我不明白你的问题 - 为什么不简单地与任何其他用户一起运行 composer？
我不以其他用户身份运行 composer 的答案是因为我想以 .sh 文件的形式运行一堆命令，并且不想在需要密码或其他交互的交互模式下运行它.
是什么让您无法运行这些命令？为什么需要通过 Composer 来触发它们？另外，为什么不首先运行具有所需权限的所有脚本呢？

标签： php composer-php root sudo

【解决方案1】：

最佳实践是完全不要将sudo 用于作曲家命令。如果您需要作曲家的sudo，它通常指向您项目的文件权限设置不正确。

例如您应该有一个拥有项目目录的非 root 用户，并且您应该以 that 用户身份运行所需的命令，而不需要 sudo。如果您需要以root 运行，这可能意味着您在之前的一次运行中这样做了，并且已经弄乱了您的文件权限。

（最佳实践也不是在任何情况下都在生产环境中运行install，但至少是you are not running update）

在极少数情况下，您需要以超级用户身份运行 composer，并且您不是在非常受限的环境中（例如，构建 Docker 映像），您应该注意 official guidance 而不仅仅是使用--no-scripts，还有参数--no-plugins，所以你只是做文件复制，不执行其他脚本。

【讨论】：

你能告诉我有项目的目录需要什么级别的权限吗？还是为整个 /var/www 文件夹设置相同的所有者和权限更好？我发现的另一个解决方案是创建临时用户来运行 composer install 但不知道这个临时用户的权限。
没什么特别的。通常，您将拥有一个不同于 www-data 的用户，该用户对该目录具有读写权限。如果所有项目都是您的并且没有其他复杂情况，您可以对/var/www 使用相同的方法。它可以简单地使用您手头的任何用户，并赋予该用户对这些目录和子目录的所有权。这是一个太宽泛的主题，无法在这里提出，但在“linux 文件权限 php 项目”和类似的东西上谷歌，你会发现大量的材料。
是的，大量的材料是问题所在。我迷失在其中。最后一个问题，如果我的用户与 www-data 不同且具有读/写权限。我可以毫无困难地运行 chown www-data:www-data ./dirPath 吗？
一般不应该执行chown www-data。您应该只需要在服务器需要写入的任何目录中执行此操作（例如，处理上传）。没有其他目录应该属于www-data。
不，它们只需要被 www 进程读取，仅此而已。 PHP 解释器读取并执行该文件。这有点超出了原始问题的范围，不是吗？

【解决方案2】：

以有权删除您所说的“文件和文件夹”的用户身份运行。如果这样的用户不存在，请创建一个，分配所有权/权限，然后在该用户下运行composer。
简单地以root 运行它只是为了删除少数已知文件夹是一个弱论点。

【讨论】：