将shell访问权授予注定要运行Apache / Nginx的用户帐户是不是一个好主意？
我问，因为在他的VPS圣经系列中，Guvnr成立了一个新的用户visudo'd
guvnr ALL=(ALL) ALL 权限，然后用该用户设置一个Nginx服务器。
而Nginx HTTP Server的作者build议您不要授予对运行Nginx的用户的shell访问权限。
您可以随时删除guvnr的shell访问权限，但是，您将如何pipe理您的网站？
编辑：@Bart Silverstrim – 下面是guvnr如何安装Nginx：
那么也许Nginx是安装在这里的根？
如果在/ etc / ssh / sshd_config中禁用rootlogin，这是否可行？
通常给shell访问任何为守护进程/服务创build的帐户都可以访问不需要shell访问的特定系统function是一个坏主意。 这样就可以防止某人打破面向互联网的服务，获得比必要的更多的权限。
基本上，为什么增加你的攻击面，如果你不需要？
另一方面，在重读这个问题时，并不清楚nginx是否有一个shell帐户。 nginx是由guvnr账户设置的，还是被授予了自己的真实账户？ 每个应用程序都由用户设置，通常具有一些pipe理访问权限。 这并不意味着它始终以该用户的身份运行（也就是说，只是因为cat是以root身份安装的，并不意味着jdoe运行的猫以root身份运行cat。）只有当nginx以guvnr的帐户权限运行或者以guvnr运行它可以访问shell; 它可能很快就会放弃权限，或者它可以拥有自己的nginx帐户，或者以一个很less或没有权限的Web用户帐户运行。 您可能需要在configuration中进行更多的挖掘，并查看服务器正在运行的内容。
由于安全。 如果用户无法获得实际的交互式shell，那么在保护服务器的时候就不必担心了。
用户是否可以使用sudo与用户无法打开shell无关。
一般来说，你想给你的用户最低的特权，他们需要做他们的工作。 服务不需要shell，所以你通常不会授权shell访问专门运行守护进程的帐户。
尤其是，如果从networking访问的服务作为特定的用户运行，最好不要给该用户shell访问权限。 原因是，如果你的服务受到攻击，那么攻击者将无法通过shell访问系统。
如果这个用户有一个shell访问权限，那么攻击者可能会有一个障碍来克服你的系统。 如果这个用户具有root权限（通过sudo ），那么如果攻击者设法欺骗系统运行一些命令，他可以用root权限来执行。
虽然有一个Web服务器运行在与shell访问的UID是你可以推理的东西，你的设置非常接近以root身份运行服务。 糟糕的想法IMO。
你如何pipe理？ 无论是“手工”还是find一个不需要您危害系统安全的工具。