我的团队需要在Red Hat 5.7上安装和pipe理一个非常大的应用程序，并且需要能够以root身份进行操作。 在项目中，Unix支持团队（负责操作系统支持）授予我们（应用程序支持团队）sudo所有的访问权限，所以我们可以这样做。 但是，我们的内部政策规定，一旦服务器运行（由我们的Unix团队正式支持并上线），除了他们之外，没有人应该拥有root权限。
为了能够明确支持有问题的应用程序，我的团队需要向Unix团队提供一个命令和访问需求的完整列表，以便他们可以授予我们sudo对所有这些命令的访问权限。 该应用程序的供应商不支持这种types的限制性pipe理，并没有一个定义的配方正确做到这一点没有问题。 这几乎是试错。
也就是说，列出我们需要运行的所有必需命令，列出每个我们需要的目录/文件访问，最好的方法是什么？
应用程序以root身份安装，其安装目录下的所有文件目前由root用户或服务用户（为应用程序服务创build的用户）拥有。
我已经开始列出带有perms u + x的所有文件，并且在未经修改的基础安装之后计算出2801个文件。 这不包括/etc/init.d中的初始化脚本和其他系统命令（如chown，chmod，ps，kill等等），我们也可能需要运行它们。
对我来说，这听起来几乎是不可能的（或者至less非常困难），而没有遇到问题。 我明白这不是一个简单的问题，可以有很多方法来做到这一点，但我仍然希望听到社区的承担。
首先，我喜欢你最初的方法来查找所有的可执行文件。 看来，供应商有一个不好的习惯，即标记一切可执行文件。 我真的希望在产品中没有2,801个二进制文件！ 您可能可以通过file传递所有这些文件，并查看哪些是实际的二进制文件，脚本等。这应该缩小范围。
其次，肯定包括停止和启动应用程序的任何要求。 听起来像供应商安装一个初始化脚本，所以这可能是你所需要的。 如果存储在系统位置（例如/ var / log）中，并且不受非特权用户读取，则还可以访问less日志文件。
最后，看看他们是否可以设置sudo规则，以便让你的团队作为服务用户运行特定的命令。 例如，您可能想以此用户身份运行vim来修改configuration文件。 如果他们想要更加严格的话，请查看configuration文件的命名约定。 也许是允许vim *.conf （或更复杂的glob或globs）的规则。
另外一个想到的问题是在未来的问题上有一个明确的升级路线。 你有没有人可以分页，如果你需要做一些捏？ 他们会监测系统的健康吗？ 如果发生应用程序故障，他们能否通知您的团队？
以下是可以被认为对你有用的一些观点（希望）：