须藤vs根; 有任何实际差异吗？

44

我正在与某个产品的支持人员一起工作，他坚持认为我必须是root用户才能安装一系列补丁，而sudo无法正常工作。他没有提供任何理由，但是他的信念似乎很坚定。浏览超级用户我无法确定是否是这种情况，并且在运行时进行确认：

sudo -l

我得到：

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

据我了解，让Linux /服务器团队真正成为root用户并不是一个立即的过程，因此我宁愿自己安装它们。

在任何实际原因上，为什么在服务器上安装软件时sudo的行为会不同于root？

linux sudo root

— 游侠
source

2

我想你应该把它还给他。正如其他人所表明的那样，有很多方法可以使用sudo扎根，如果他不能向您提供有关sudo不足的具体原因，那么他就没有立足之本。

— 加勒特2014年

1

我想到了环境和子命令。我认为Hastur在环境方面做得很好，而Jayen在子命令，管道和重定向方面做得很好。

— jww

2

加勒特（Garrett）有一个很好的观点，但是在我参加一个潜在的小便竞赛之前，我会问支持者：您是否尝试过这两种方法，但其中一种方法失败了？sudo由于脚本的当前编写方式，他可能和脚本一起走在了失败的道路上。如果是这种情况，那么sds的答案可能对您最有帮助：sudo su -。

— jww

34

这在很大程度上取决于您如何使用sudo或调用程序su。
例如，在此刻我所在的系统上：

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

其中[1] = / usr / local / sbin：/ usr / local / bin：/ usr / sbin：/ usr / bin：/ sbin：/ bin
Env =将环境变量重置为1和5，取自$ USER in 2,3,4。

因此，一个脚本，或与不同的选项可以看到不同的启动了一项计划$PATH，$HOME其外壳可以读取不同.bashrc，.profile和环境变量。它读取与相关的文件$HOME。每个用户可以以不同的方式（变量$PATH，.bashrc，.profile，.bash_profile，别名...）修改其环境。特别是，用户可以在其目录中使用不同顺序的目录，$PATH因此，脚本可以执行命令，例如，/home/$USER/bin从根目录开始，然后从路径中选择一个命令。

您可以在sudo -i以root身份登录的情况下在该程序下运行该程序su -，但是如果使用sudo MyCommand或来运行该程序，则可能会有不同的行为su -c MyCommand。

来自man su：

在描述部分：
当前环境传递给新的shell。对于普通用户，$ PATH的值将重置为/ bin：/ usr / bin，对于超级用户，$ PATH的值将重置为/ sbin：/ bin：/ usr / sbin：/ usr / bin
...
在选项部分：
-，- l ，--login
提供类似于用户直接登录该用户所期望的环境。

从人 sudo

-i，--login
运行目标用户的密码数据库条目指定的外壳程序作为登录外壳程序。这意味着Shell将读取特定于登录的资源文件，例如.profile或.login。如果指定了命令，则通过外壳的-c选项将其传递到外壳以执行。如果未指定命令，则执行交互式外壳程序。 sudo尝试在运行外壳程序之前更改为该用户的主目录。 该命令在与用户登录时会收到的环境类似的环境下运行。sudoers（5）手册中的“命令环境”部分记录了使用sudoers策略时-i选项如何影响运行命令的环境。

— 哈斯图尔
source

好答案。我仍然是Linux的新手，但是另一个不同之处是，您可以使用的sudo操作可以受sudoers文件中的权限的限制，而以root身份执行操作则没有这些限制？最后的引号可能暗示，但是，如果我理解正确，那似乎是除环境之外的另一个实质性差异（或者可能是由于环境？）。

— fixer1234 2013年

23

如果您具有完全sudo访问权限，则可以root使用sudo su -，因此安全点没有意义。

确实，有一种方法可以区分使用- 与- root运行的程序之间的差异，但这是一个人为设计的技巧。为什么补丁系统会这样做？sudogetuidgeteuid

— sds
source

5

说到su -，他可能想要使用sudo -i以便与直接登录时具有相同的环境。

— Cristian Ciupitu 2014年

2

如果您使用例如eg来运行，sudo myscript则将从您所在的shell中保留$ PATH和环境变量。如果与sudo -i myscript您一起运行，则就像您以root用户身份登录一样运行。请看我们的_zoo呼叫

— Hastur

1

我认为必须指出，环境变量可能与sudo以root用户身份登录时设置的环境不同

— secretformula 2014年

1

@dmanexe：sudo并不代表超级用户，而是“切换用户”。su和sudo可用于切换到任何用户，而不仅仅是超级用户。sudo也没有伪的东西，您在运行sudo时真正获得了实际的根，而没有任何伪造的东西。请注意，sudo的魔力实际上来自setuid权限位。

— Lie Ryan

2

SDS，@CharlesDuffy：有观点认为，须藤和苏事业geteuid()，并getuid()为彼此不同的是一个神话。su和sudo在运行指定的命令或shell之前，将实际用户ID和有效用户ID都更改为目标用户的ID，除非在非常不寻常的情况下，您已将它们明确配置为其他行为。您可以通过运行sudo id -u和sudo id -ru（都显示0），读取sudo（8）（在COMMAND EXECUTION下）或编写测试程序来验证（对于sudo）。

7

如@Hastur所指出的，如果要获得根shell，会有一些区别。

如果您没有获得root shell，则还有更多区别。支持成员可能具有尝试执行以root身份sudo patch -p0 < /root/patch.file在何处patch运行等操作的经验，但<（从文件进行管道操作）却没有。

— 杰恩
source

1

正确：实用的观点通常会提供一些提示，这些提示仅在手册页中很难发现。为了克服类似的情况，您被迫做更多的运动 [:-)]例如写类似的东西sudo /bin/bash -c "./patch -p0 < /root/patch"。使用重定向创建文件时，情况更加复杂>。第一种方法是，只有在您有足够的权限写入最终目录时，才创建属于用户的文件。通过后一种方式，您将创建一个由root拥有的文件... Unix的黑暗面;-)

— Hastur 2014年

1

我相信使用sudo访问时会创建一个日志文件，但是直接通过root访问运行时却没有。

— Ashley Redman理学士
source

0

这取决于您希望根访问权限的粒度。如果您有多个用户在系统上执行不同的任务，那么sudo更为理想。我经常使用的一个示例是需要重新启动应用程序或数据库。最好总是以最小特权来确保安全。我使用组，仅允许这些组执行明确的操作。一本描述此过程的好书是“ Sudo Mastery：针对真人的用户访问控制”。其实这是一本关于sudo的好书。

— 梅里迪思克
source