我们非常庞大的组织已经开发了一个应用程序托管标准，该标准规定应用程序及其依赖的所有组件必须驻留在与操作系统本身不同的专用应用程序卷中。例如，如果应用程序是用 Perl 编写的，我们需要在应用程序卷中维护一个单独的 Perl 实例。
这背后的原因是那些被操作系统和应用程序所依赖的组件可能并且经常有冲突的版本要求，并且强制应用程序维护自己的资源可以更容易地修补操作系统。此外，它还确保应用程序数据和日志不会被塞入基于操作系统的工具所在的位置（例如，这对于 httpd 尤其重要）。
此外，除非存在有效且记录在案的技术原因，否则应用程序进程必须以非特权用户身份而不是 root 身份运行。我们在 Linux 中制定了解决方法，以便诸如 Web 服务器之类的进程可以作为非特权用户运行，并接受从特权端口（80 和 443）转发到它们正在侦听的非特权端口的连接。
从角度来看，我是我公司 Unix/Linux SA 组织的一名安全专家，我与平台技术支持专家密切合作，以维护和执行我在上面列出的标准。我的很大一部分职责是通过集中管理的 sudo 审查特权访问请求。我们的标准 Linux 是 Red Hat，但 Ubuntu 和 CentOS 也在考虑用于云环境。
问题是我们目前正受到来自应用程序团队的要求允许他们（通过 sudo）使用 rpm 和 yum 安装 Linux 应用程序的请求，因为供应商需要这样做并且无法提供任何替代方法来安装应用程序。这在多个方面与我们的标准相冲突：
rpm 和 yum 工具必须以 root 权限运行。这意味着他们所做的一切都以 root 身份运行，因此最终的安装必须经常在事后进行调整，以允许它以非特权用户身份运行。
包通常指定组件必须安装在根卷中，而不是在指定的卷下。在可以指定包树的根的地方，供应商通常坚持它保持不变，因为他们只在包中指定的精确环境中对其进行了测试。
最后，rpm 和 yum 从系统可用的任何存储库中获取依赖项，尽管我们要求应用程序使用我们的卫星存储库来获取 Red Hat 提供的任何内容，但供应商通常会提供他们自己的存储库，这些存储库必须包含在内，软件才能正常工作。
我的问题是，如何在这样的环境中指定或限制使用rpm和yum，以确保不会发生包冲突并可以安全地应用系统安全补丁，同时不完全禁止将这些工具用于应用软件（直到现在我们一直在做并且发现它是徒劳的）？