在 Linux 上以特权用户身份通过 PHP/Perl 脚本运行命令
背景：我正在为一家公司编写一个脚本，该脚本将允许用户通过 Web 界面创建 FTP 帐户。在后台，脚本必须运行一堆命令：
- 将用户添加到系统（useradd）
- 打开并编辑各种文件
- 通过 sendmail 向用户发送邮件
以及其他一些事情...
我基本上正在寻找 最安全的方法。我听说过 setuid 方法、sudo 方法，当然还有以特权用户身份运行 httpd。当然，在执行任何命令之前，都会对输入的数据进行完整性检查（即，用户名中仅包含字母数字字符）。
流行脚本（例如 webmin）使用的方法是什么，因为它必须相当安全？
Background: I am writing a script for a company that will allow users to create FTP accounts through a web interface. In the background, the script must run a bunch of commands:
- Add the user to the system (useradd)
- Open and edit various files
- mail the user via sendmail
and a few other things...
I'm basically looking for the most secure way of doing this. I've heard of the setuid method, the sudo method, and of course, running httpd as a priviledged user. There will be sanity checks on the data entered of course before any commands are executed (ie. only alphanumeric characters in usernames)
What is the method used by the popular scripts out there (webmin for example), as it must be fairly secure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会设置一个队列，Web 绑定脚本可以写入该队列。
然后我会从该队列中读取一些特权进程并采取适当的操作。您可以通过 cron 作业驱动命令行脚本，或者用 PHP 编写一个小守护程序来检查队列并比 cron 允许的更频繁地执行工作。
这样，唯一可以以特权运行的代码就是您的小工作脚本，并且您不需要为 Web 绑定脚本提供任何路径来获得必要但危险的特权。
I would set up a queue that the web-bound script can write to.
Then I'd have some privileged process read from that queue and take appropriate action. You could drive a command-line script via a cron job, or write a little daemon in PHP that checks the queue and does the work more frequently than cron allows.
That way, the only code that can run privileged is your little worker script, and you don't need to provide any path for the web-bound script to gain the necessary but dangerous privileges.
创建一个接受命令行选项、验证它并执行 useradd 的脚本。使用 NOLOGIN 指令将您的 httpd 用户添加到 sudoers 文件中，仅用于该进程。
这样，您就不必担心编写始终以 root 权限运行的守护程序，并且您的脚本也会立即返回。如果您刚刚使用了 setuid root 脚本，则同一系统上的其他用户可以执行您的脚本（除非您检查了他们的真实用户 ID）。
Create a script that accepts a command line option, validates it, and execs useradd. Add your httpd's user to the sudoers file with a NOLOGIN directive, JUST for that one process.
That way, you don't have to worry about writing a daemon that will always run with root privileges, and your script would also return immediately. If you just used a setuid root script, other users on the same system could exec your script (unless you checked their real user ID) .
我首先要说的是，以 root 身份运行 httpd 是一个非常糟糕的主意。
最安全的方法是在 Web 服务器 UI 和效应器之间实现完全的权限分离 - 一种明显的方法是以 root 身份运行服务器，仅接受 UI 向其发送请求的本地连接（一个简单的方法是通过 inetd/xinetd - 这意味着您不必费心建立守护进程的所有复杂问题）。
您还需要 UI 和效应器之间存在某种信任机制（共享秘密就足够了），以便系统上的其他程序无法调用效应器。使用依赖于基于质询的身份验证或非对称加密的信任系统意味着您不再需要担心本地连接限制。
最后，您需要一个定义明确的协议来供 UI 和效应器进行通信。
这比使用 sudo 复杂得多，但更安全（例如 sudo 只允许用户以不同的 uid 身份执行特定文件 - 您希望该文件包含正确的程序）。
Setuid 具有许多与 sudo 相同的缺点，但增加了复杂性：（在大多数情况下）如果它启动另一个程序 - 那么它将像原始 uid 一样执行。
HTH
C.
I'll start by saying that running httpd as root is a very bad idea.
The safest way to do this is have complete privilege separation between the webserver UI and the effector - one obvious way of doing that is to run a server as root accepting local connections only which the UI sends its requests to (a simple way of doing this is via inetd/xinetd - which means you don't have to bother with all the complications of establishing a daemon process).
You would also need some sort of trust mechanism between the UI and the effector - a shared secret would suffice - so that other programs on the system can't call the effector. Using a trust system which relies on challenge based auth or asymmetric encryption means that you no longer have to worry about the local connection constraint.
Finally, you need a well defined protocol by which the UI and effector communicate.
This is a lot more complex than using sudo, but is more secure (e.g. sudo just allows users to execute specific files as a different uid - you hope that the file contains the right program).
Setuid has many of the same drawbacks as sudo with the added complication that (in most cases) if it starts another program - then it will do so as the original uid.
HTH
C.