postgresql - 关于连接句柄重用和数据库用户设计的 "best practices"是否相互排斥？

Question

SO 说这可能是主观的。我希望不会——我似乎无法理解这在实践中是如何工作的，这似乎是一个足够具体的技术问题，我希望得到一个明确的答案。

上下文:LAPP 堆栈。

1. 我读到过，使用单个数据库用户作为所有数据库连接的登录名，并从那里自己处理安全问题，这不是一个好主意。数据库有足够的安全模型，使用它们很有意义。

2. 数据库句柄有一些与之相关的资源成本，因此存在 Apache::DBI、DBIx::Connector 和 DBI::connect_cached()，以重新使用最近的数据库连接。使用它们应该可以避免连接到数据库的成本，从而使 Web 应用程序更快。

这些最佳实践似乎相互排斥的原因是，根据我的理解，#1 意味着任何数据库连接都将使用单独的每个用户凭据进行，这意味着(如 Apache::DBI documents )重新使用此类连接可能会很快导致您的数据库后端耗尽连接。

PostgreSQL 的默认最大连接数是 100。

对于使用 prefork MPM 运行的 Apache 2，服务器的默认数量乘以每个允许的子进程，远远超过了这个数量，因此 Apache::DBI 的文档似乎是正确的。

因此问题:人们在实践中会做什么？

这是否意味着使用 LAPP 堆栈的人通常使用单个数据库用户进行连接，并实现他们自己的安全/权限模型？或者这是否意味着他们不共享连接？或者，如果他们使用 LAPP 堆栈，他们是否会根据速度与安全需求在这两种策略之间进行选择，如果他们需要两者，则使用桌面应用程序或其他连接模型？

或者如果这些实际上不是相互排斥的策略，那么我在这里的理解中遗漏了什么？

Answer 1

I've read that using a single database user as the login for all connections to the database, and handling security yourself from there, is a bad idea. Databases have sufficient security models and it makes sense to use them.

您可能误读了此内容，或者在非常有偏见的位置阅读了它。一个更平衡的观点是(希望如此):

• 在数据库中管理权限(ACL 或 RBAC 或其他)是一团糟而且很难正确处理。如果操作不当，它也会削弱性能(想想:“select * from table join perms where convoluted_permission_scenario”。)根据你问的人，你会得到或多或少的极端观点，例如这是(非常有争议的)Zed Shaw:http://vimeo.com/2723800 .

• 在数据库级别管理权限同样是一团糟。并非所有引擎都实现行级权限，即使这样偶尔也会出现泄漏。例如，如果 raise 被调用，在 where 子句中调用函数可能(可以？)泄漏 Postgres 中的行(直到最新版本？)。坦率地说，如果您不对正在发生的事情进行肤浅的分析，它基本上相当于前者 — 只是标准化并且(通常)在 C 中。

• 在没有数据库的情况下在应用程序级别管理权限也是一团糟。从需要加入 SQL 之外的那一刻起，无论您做什么，它都会削弱性能，除非您处理的数据量很小。如果你尝试一下，你会做得很好……直到你的数据库变得太大而你基本上不会。

所以，简而言之:无论您在哪里管理，这都是一团糟。因为权限一团糟。除了随意理想化的“Joe 需要对这组节点的写权限”之外，你还需要应对更接地气的场景，比如“John 圣诞节要去度假，需要临时将他的写权限委托(delegate)给这套节点给他的助手简”。此外，无论您选择哪种方案，您需要以快速的方式管理读取访问(这通常是最频繁的)以便您可以扩展。没有 Elixir 。

此外，即使在上述第一个和最后一个场景中，拥有三个数据库用户也是最理想的。一种用于读取，一种用于读/写，一种用于模式更改。大多数应用程序不这样做，因为以这种方式配置 ORM 又是一团糟，因此每个应用程序通常只有一个数据库用户。

无论如何，回到你的问题:人们在实践中所做的是一个或两个数据库用户(读 vs 读/写/修改)，在数据库本身内实现 RBAC 或 ACL，并避免像瘟疫一样的访问限制逻辑出于性能原因面向公众的页面。