我有一些名为foo的程序在执行时需要root权限。 foo需要能够被任何用户运行，并且可以位于任何path。 这个程序可以在任何path的原因是因为我们公司正在开发程序foo和每个用户可能有一个个人目录中的程序的个人版本，而他们的工作。
我的问题是，这是最安全的方式来处理这个问题？ 我一直在研究sudoers文件，基本上有两个想法。
）列出程序可以在sudoers文件中的所有path。 这是有问题的，因为它需要频繁编辑sudoers列表，并且仍然存在安全风险，因为非root用户将拥有他们的foo个人副本并且可以将某些系统程序复制到foo然后以root身份使用它。
2.）编写一个名为start_foo的脚本，对传入的程序（如大小和名称）执行一些inputvalidation，然后启动传入的foo。 start_foo可以在/ usr / bin中生存，并由root拥有，但可以由任何人运行。 这个选项还包括能够用另一个根需要程序写用户foo程序的安全漏洞，但希望大小检查能够捕获一些恶意的情况。
有没有一种“无用的”方法来解决我没有发现或想到的问题？ 如果不是上述哪个或其他解决scheme是解决问题的最佳方法？
谢谢！
最安全的方式来处理它可能会给你的每个开发人员他们自己的小开发/testing环境，也许是一个虚拟机。 这样，他们只能打破自己的发展实例。
一个明显而且最安全的解决scheme是创build一个新的特权守护进程应用程序food ，它处理foo应用程序应该以root身份执行的操作，然后foo应用程序使用例如。 套接字（Unix，TCP）。 如果您的foo应用程序受到攻击，攻击者将只能与food进行通信， food会有一个有限的命令集。
如果你信任你的同事，你可以将它们添加到unix-group foodevel ，使用解决scheme2），然后只允许执行foo程序（如果它们属于这个组）。 属于某个特定组的人可以对文件发出chgrp命令，另一个人将不能。
另外，您可以检查一个sUID字节解决scheme，而不是依赖于sudo。 这可能不是每一种编程语言都很好的支持，你需要了解一下有效的权限（check man seteuid ）。
也许使用某种chroot监狱 。 可能根据需要使用应用程序需要运行的各种文件进行dynamic创build。
这提出了一个巨大的问题，因为那么用户可以在任何时候编辑脚本。 即使文件是只读文件，它们也会在它所在的目录上写入权限。
出于这个原因，你需要将root-priv脚本放在你的控制之下
你能做点什么吗？
/ home / central / [scriptname] <—-根写入目录，世界可读。 这个你可以给sudo访问
然后/ home / [anyuser] / scriptname <—不是sudo访问
而scriptname是/ home / central / [scriptname]的封装
那会更好，更可行
和/ home / [anyuser] / scriptname会是类似的
#!/bin/bash /home/central/[scriptname] $@ # pass all arguments