PgBouncer安全认证函数中的search_path风险与最佳实践

在PgBouncer连接池的官方文档中，提供了一个用于auth_query的安全函数示例。这个函数使用了SECURITY DEFINER权限执行，但存在一个潜在的安全隐患：它没有设置search_path参数。

SECURITY DEFINER函数在PostgreSQL中会以函数创建者的权限执行，这意味着它需要特别关注安全性。当这类函数没有显式设置search_path时，可能会受到search_path注入攻击的影响。攻击者可以通过创建临时表或视图来劫持函数中对系统表的引用。

文档中的示例函数虽然目前是安全的，因为它显式地使用了pg_catalog.pg_authid这样的完全限定名称，但存在两个问题：

1. 如果用户修改这个函数时去掉了pg_catalog前缀，就会立即变得不安全
2. 良好的安全实践要求所有SECURITY DEFINER函数都应该显式设置search_path

推荐的修复方案是在函数定义中加入：

SET search_path = pg_catalog, pg_temp;

这里特别包含pg_temp是因为PostgreSQL的搜索规则会优先检查pg_temp中的对象，即使search_path为空。因此仅设置search_path = ''并不能完全防止这类攻击。

这个案例提醒我们，在编写SECURITY DEFINER函数时应该遵循以下安全准则：

1. 总是显式设置search_path
2. 优先使用完全限定的对象名称（schema.object）
3. 最小化函数所需的权限
4. 仔细审查所有动态SQL的使用

虽然当前文档中的示例函数本身没有漏洞，但作为官方文档提供的示例，应该展示最佳安全实践，避免用户基于此开发时引入潜在风险。这也是为什么建议更新文档中的示例代码。

对于使用PgBouncer的管理员来说，在实现自定义认证函数时，应该特别注意这些安全细节，确保连接池的认证环节不会被恶意利用。