须藤与根；任何实际差异？

Question

我正在与一个产品的支持成员一起工作，他坚持说我需要成为 root 才能安装一系列补丁，而 sudo 不起作用；他没有提供任何理由，但他的信念似乎非常坚定。浏览超级用户我无法确定出现这种情况的任何可能原因，并确认，当我运行时：

sudo -l

我得到：

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

据我所知，从 Linux/服务器团队获得真正的 root 访问权限并不是一个直接的过程，所以我更愿意自己安装它们。

是否有任何实际原因为什么 sudo 在服务器上安装软件时的行为与 root 不同？

Answer 1

这在很大程度上取决于您如何使用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因此，脚本可以执行命令，例如 in/home/$USER/bin而不是从 root 期望的路径中的命令。

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

来自man su：

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

从人 sudo

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

Answer 2

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

事实上，有一种方法可以区分程序运行方式root和程序运行方式之间的区别sudo- 使用getuidvs geteuid- 但这是一个人为的技巧。为什么补丁系统会这样做？

Answer 3

正如@Hastur 所指出的，如果您获得的是 root shell，则存在一些差异。

如果您没有获得 root shell，则存在更多差异。支持成员可能有尝试执行诸如以 root 身份运行sudo patch -p0 < /root/patch.filewhere 之类的事情的经验patch，但<（从文件中传输）则不然。