比特币节点的 RPC 默认只监听本机回环地址，这是绝大多数部署安全的前提。但一旦你要把 P2P 端口所在的服务器交给多人或多服务共用，“谁能读 RPC 密码”就从理论问题变成了具体的文件权限问题。-rpccookieperms 就是针对这个场景的参数：它决定 RPC 鉴权用的 cookie 文件对哪些人可读，共三档——owner、group、all。
一、cookie 鉴权是怎么工作的
比特币核心启动时若没配置 rpcauth 用户名密码，会在数据目录生成一个一次性 cookie 文件（默认 .cookie），内容是一串随机凭据。同机的合法客户端（例如 bitcoin-cli）通过读取这个文件完成 HTTP Basic 认证。cookie 的价值在于免配置，弱点在于它就是一个明文文件——所以它的保密性完全押在操作系统文件权限上。默认行为是用 umask 0077 创建，只有启动进程属主能读。
二、三档权限各解决什么问题
-rpcauth 场景在多用户服务器上很常见：备份脚本用一个普通账号跑、监控采集用另一个账号跑，它们都需要读 cookie 才能发起 RPC 查询。三档设置对应三种信任半径。owner 是默认，只有属主用户可读，最严格；group 把可读面扩大到属组，配合把运维账号拉进同一个组，可以做到”不给 root 也能查节点”；all 让任何本机用户可读，相当于放弃文件层的机密性，只应出现在”这台机器上没有任何不可信进程”的假设完全成立的场合——而共享服务器恰恰不满足这一条。
三、它管不到什么
rpccookieperms 只影响 cookie 这个文件。RPC 的监听地址由 -rpcbind 决定，默认 127.0.0.1；就算 cookie 全世界可读，远程攻击面仍然由绑定地址把门。反过来，开了远程绑定，cookie 泄露只是把攻击门槛从网络层降到本机一层。RPC 通道本身没有 TLS 加密，这一点比特币核心的发布说明写得明白——自 v0.20 起 HTTP 层不再使用 OpenSSL。所以任何跨机器的 RPC 访问都应走 SSH 隧道或本机反代加密，而不是指望权限参数替你保密内容。
四、典型部署与对应取值
个人单用户主机：保持默认 owner，不要为省事改宽。小团队共用一台全节点：建一个 bitcoin-rpc 用户组，把监控和备份账号加入该组，启动进程属组设为它，配置 -rpcauth 为不同账号签发不同哈希（比共享 cookie 更容易单独吊销），cookie 保持 owner 也可以。只有当多个无法统一属主的服务确实要共用同一个 cookie 时，才考虑 group，并审计组内成员。all 基本没有正当场景；若真有”本机人人可读”的需求，说明该迁到 rpcauth 多用户方案了。
五、与白名单、多用户的组合拳
cookie 是”一把公共钥匙”，rpcauth 是”一人一把钥匙”，-rpcwhitelist 则决定每把钥匙能开哪些门——三者正交。把 cookie 权限放宽却不配白名单，等于把所有 RPC 命令暴露给整组用户，包括 sendtoaddress 这类动钱的命令。检查顺序建议：先确认 cookie 文件的实际权限位（ls -l 数据目录），再确认是否有账号在用它，再确认这些账号有没有被白名单限制为只读命令。三个问题都答得上来，这台机器的 RPC 访问模型才算清晰。
六、注意事项与例外
若你显式配置了 rpcusers 形式的静态凭据，cookie 文件仍会生成但不作为主鉴权路径；此时放宽 cookie 权限纯属扩大暴露面。settings.json 中保存的运行参数不会做脱敏，排查配置泄露时别只盯日志——日志里的敏感参数会被打码，设置文件不会。cookie 文件在重启后重新生成，属主和权限以启动进程的有效用户与启动时的 umask 为准，改参数后必须重启才生效。另外，若数据目录被挂载在禁用权限位的文件系统上，chmod 的效果会失效，这也是多用户服务器上偶发的隐性坑。
风险提示：本文所述行为以 Bitcoin Core v31.0 源码与官方文档核对为准，不同版本参数默认值可能不同。RPC 访问控制直接关系钱包资金安全，任何放宽权限的改动都应先评估服务器上的不可信进程面，本文不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。