我们非常大的组织已经开发了一个托管应用程序的标准，该标准规定应用程序及其所依赖的所有组件必须驻留在与操作系统本身不同的专用应用程序卷中。例如，如果应用程序是用 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 从系统可用的任何存储库中提取依赖项，尽管我们要求应用程序使用我们的 Satellite 存储库来获取 Red Hat 提供的任何东西，但供应商通常会提供他们自己的存储库，软件必须包含这些存储库才能运行。
我的问题是，如何在这样的环境中指定或限制使用 rpm 和 yum 以确保不会发生包冲突并可以安全地应用系统安全补丁，同时又不完全禁止将这些工具用于应用程序软件（直到现在我们一直在做并且发现这是徒劳的练习）？