我有一个程序安装在 /opt 下的自定义目录中。为了更容易运行它，我编辑了我的 bashrc 以将所述目录添加到我的路径中：
export PATH=$PATH:/opt/godi/bin:/opt/godi/sbin
如果我想在没有 sudo 的情况下运行程序，这很好用。但是，如果我尝试使用 sudo 运行它，它会因“找不到命令”错误而失败。
$ sudo godi_console
sudo: godi_console: command not found
使用 sudo 后检查 PATH 变量表明它不包括我作为普通用户所拥有的相同 PATH：
$ sudo sh
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
为什么 PATH 不一样？难道我做错了什么？我在 Debian Jessie 上，如果它有所作为。
我尝试的一件事是直接调用 /opt/godi/sbin/godi_console，将绝对路径传递给可执行文件。不幸的是，这在这种特殊情况下没有帮助，因为 godi_console 本身取决于正确设置的 PATH。
即使我的非特权用户受到威胁，我也希望 root 帐户安全。
在 Ubuntu 上，默认情况下您只能出于“安全原因”使用 sudo。但是，我不确定它是否比仅在文本模式控制台上使用登录更安全。如果攻击者可以以我的普通用户身份运行代码，那么可能会出错的事情太多了。例如添加别名、向我的 PATH 添加东西、设置 LD_PRELOAD 和 X11 键盘记录器等等。我能看到的唯一优势是超时，所以我永远不会忘记注销。
我对 su 也有同样的疑问，但它甚至没有时间限制。某些操作（尤其是 IO 重定向）对 su 更方便，但在安全方面这似乎更糟。
在文本模式控制台上登录似乎是最安全的。由于它是由 init 启动的，如果攻击者可以控制 PATH 或 LD_PRELOAD，那么他已经是 root。按键事件无法被 X 上运行的程序拦截。我不知道 X 上运行的程序是否可以拦截 [ctrl]+[alt]+[f1]（并打开一个看起来像控制台的全屏窗口）或它就像 Windows 上的 [ctrl]+[alt]+[del] 一样安全。除此之外，我看到的唯一问题是没有超时。
所以我错过了什么吗？为什么 Ubuntu 的人决定只允许 sudo？我可以做些什么来提高任何方法的安全性？
SSH呢？传统上 root 不能通过 SSH 登录。但是使用上述逻辑不是最安全的做法：
在经历了令人沮丧的头砖墙接触之后，我发现了这一点：
$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/steve/bin
$ sudo bash
# echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin
但
$ sudo bash -c 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin
$ sudo bash -Ec 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin
我从另一篇文章中收集到sudo路径是从中读取的/etc/sudoers- 但为什么呢？设置是否$PATH在/root/.profile任何意义，或者是只是上面的混乱配方（即产卵实际外壳导致不同$PATH的是，在不经意中使用sudo的命令......）？
我在 RHEL 6.4 上使用 bash。
当我运行 sudo 时，我的环境到底发生了什么？
当我运行时sudo command，它似乎没有看到我或 root 的环境。例如，我的两个路径都包含/usr/local/bin，但是如果我尝试在没有完整路径的情况下运行程序之一，则会失败。
我以为 sudo 以 root 身份运行，因此获得了 root 的环境。bash 在 sudo 下执行的方式与在 root 或我的普通用户下执行的方式不同吗？
编辑：
我sudo -i最近一直在使用，但最近它引起了问题，因为我当前的工作目录被设置为/root. 这符合预期（有点），但我仍然不明白为什么 sudo 无法识别我的/usr/local/bin.
编辑：
我正在运行 Fedora 15。
示例命令：
drush cc all
有效，但这：
sudo drush cc all
给我：
sudo: drush: command not found
为什么？如何解决这个问题？