以其他用户身份执行作业

Question

通常，以其他用户身份执行Jobs时，我们可以执行sudo -u <user> <cmd> 。 但是，如果需要永久的流程，我们必须这样做：

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

参考： https : //superuser.com/questions/213416/running-upstart-jobs-as-unprivileged-users

这有什么不同？ 这是什么意思？ 此外：

su -s /bin/bash -c bash username -- /path/to/command [parameters...]

似乎不起作用！

Answer 1

第一个：

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters]

以root以外的用户身份启动upstart工作的目的是允许更改用户标识而不会留下中间过程； 因此它以以下方式运行：

• exec su -s sh
  使用su替换调用此命令的进程，并运行shell sh
• -c 'exec "$0" "$@"'
  从shell sh exec的调用开始，在--之后传递命令和参数（ $0是命令行上的第一个参数，在-- ， $@之后的所有内容）

最终产品正在运行/path/to/command 就像直接使用指定的username从命令中调用它一样； 留下一个过程树，如下所示：

su [as root] -> /path/to/command [as username]

如果不使用exec调用它，那么最终将得到一个如下所示的进程树：

upstart_launcher [as root] -> su [as root] -> sh [as username] -> /path/to/command [as username]

（我不知道此时的upstart_launcher进程是什么样子；我没有一个带有upstart的系统来检查这一点；但是会剩下一个进程）

现在，一个重要的元素是它只调用exec /path/to/command [arguments…] ，就好像它是从命令行键入的一样。

当我们将其与第二个命令行进行比较时； 发生的大部分事情都是相似的 ，但并不完全相同：

su -s /bin/bash -c bash username -- /path/to/command [parameters...]

为什么不起作用？ 好吧，您已经要求它做一些不同的事情； 在这种情况下; 你问它来运行该命令bash从shell bash 。

因为您没有传递$0或$@ ，所以--之后的所有内容都将被忽略，因为它不会传递给被调用shell的-c 。

有和没有exec的示例

这会使过程树崩溃，除去中间的sh这是一种防止深度过程树的内部管理机制。

跳过所有执行程序（ su -s /bin/sh -c '"$0" "$@"' proxy -- pstree -aApl ）：

bash,1
  `-bash,1014
      `-su,1017 -s /bin/sh -c "$0" "$@" proxy -- pstree -aApl
          `-sh,1018 -c "$0" "$@" pstree -aApl
              `-pstree,1019 -aApl

添加内部exec（ su -s /bin/sh -c 'exec "$0" "$@"' proxy -- pstree -aApl ）-注意缺少的第二层sh ：

bash,1
  `-bash,1014
      `-su,1020 -s /bin/sh -c exec "$0" "$@" proxy -- pstree -aApl
          `-pstree,1021 -aApl

添加内部和外部exec（ exec su -s /bin/sh -c 'exec "$0" "$@"' proxy -- pstree -aApl ）-注意缺少外部级别bash ，并且1014 pid是与之前bash调用中存在的pid相同：

bash,1
  `-su,1014 -s /bin/sh -c exec "$0" "$@" proxy -- pstree -aApl
      `-pstree,1022 -aApl