运行# su - oliver --command bash给出一个shell，但是也会打印出警告bash: no job control in this shell ，而Ctrl + Z和fg / bg在那个shell中不起作用。
运行# su - oliver --session-command bash给出一个没有打印警告的shell，而且作业控制确实有效。
使用--session-command的build议来自于使用su启动shell脚本中的结果“在该shell中没有作业控制” ，其中声明“[su的安全修复]改变了-c选项的行为并禁用了作业控制在被调用的shell内“。
但是我还是不太明白这一点。 什么时候应该使用--session-command什么时候应该使用 – --session-command ？ – 命令（aka -c ）更安全吗？ 还是应该总是使用--session-command ，并且 – 为了向后兼容，只剩下--command ？
FWIW，我正在使用RHEL 6.4。
一般来说，你应该首选--command （-c）到--session-command 。 你不应该用交互式shell（也许你想要--shell /bin/bash ？）使用-c，但是你应该使用后台进程。
–session-command不会调用setsid（）来分配一个新的会话（就像你发现的那样，允许继续使用控制的tty，因此bash会给你一个交互式shell的进程控制权）。 这意味着它的孩子可以被分配到父会话的任何进程组，或许会话前景pg或避免killpg（）或其他基于进程组ID的分类。 它还保留了将SIGCONT发送到会话中的任何进程的能力，但我不确定这是多么可恶。
考虑到--session-command不在我听说的任何主要发行版的man页面上，这可能是一个自定义的RHEL事情（谷歌也没有帮助）。
-c使su执行指定的命令，使用/etc/passwd为指定用户定义的任何shell。 这使得它很像sudo ，但无论你select哪个用户，并知道密码。 -c不提供交互式shell，所以需要tty的任何东西都不起作用。
我也发现使用-c不会创build一个tty：
# su nobody -s /bin/bash -c "echo hi >/dev/tty" bash: /dev/tty: No such device or address # # su nobody -s /bin/bash --session-command="echo hi >/dev/tty" hi #