风险：隐蔽权限修改导致rgw服务中断

上午正在开会，突然收到rgw服务异常的告警（503 Service Unavailable），立马停下来处理告警，避免影响到用户~

我们的rgw frontend用的是apache，之前也遇到过503的问题，经验上反应出应该是/var/run/ceph的目前权限出了问题导致apache进程无法访问到rgw的fastcgi.sock文件，从而导致503。按这个思路去查，果然，所有rgw机子的/var/run/ceph（owner和group均为ceph）的权限都从0777变成了0770！！！

恢复服务为重，先把所有的权限修改正确，再细查权限变化的原因~

那么问题来了，到底是谁修改了/var/run/ceph的权限？

尝试在网上寻找类似的问题，没有发现，自力更生~

嫌疑人	分析
人为	rgw这些机子和服务是由我负责的，应该不会有人操作这些机子，暂时排除这个可能
cron任务	没有找到可能做修改的周期性任务
ceph组件进程	ceph各组件已经稳定运行了一年多，服务一直正常，而且组件进程也没有重启过，组件进程修改的可能性较小
...	:(

当你迷茫的时候，不妨看看源码，在ceph的源码中搜索“/run/ceph”，发现了这样的一个文件systemd/ceph.tmpfiles.d，内容是这样的：

d /run/ceph 0770 ceph ceph -

我们的/var/run/ceph目录就是被改成了0770权限，直觉告诉我们，遇到的问题跟这个目录有千丝万缕的联系... 从ceph.spec.in看出，这个文件最终安装成了/usr/lib/tmpfiles.d/ceph-common.conf ，涉及到systemd tmpfiles机制，临时抱佛脚学习下 systemd tmpfiles机制 ~

d /run/ceph 0770 ceph ceph -
对于这条配置，开机时systemd-tmpfiles-setup服务会创建owner和group为ceph、权限为0700的目录/run/ceph；而systemd-tmpfiles-clean服务会周期性（周期为天，可通过systemctl list-timers --all查看）遍历/run/ceph下的文件，根据配置来进行删除，这里配置的是“-”，意为不进行删除

而systemd-tmpfiles-setup服务最终执行的命令为：

/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev

做个测试，我们创建了内容为“d /run/test 0770 ceph ceph -”的文件/usr/lib/tmpfiles.d/test.conf，然后执行上述命令，果不其然，/run/test目录创建出来了：

root@c144:~$ ll /run/ |grep test
drwxrwx--- 2 ceph ceph 40 Jan 17 09:26 test

我们把/usr/lib/tmpfiles.d/test.conf内容改成“d /run/test 0777 ceph ceph -”，再执行命令，权限发生了变化：

root@c144:~$ ll /run/ |grep test
drwxrwxrwx 2 ceph ceph 40 Jan 17 09:26 test

那问题又来了，谁调用了/usr/bin/systemd-tmpfiles？

不卖官司了...是这样的：

运维人员更新了systemd的rpm，而systemd rpm的post install脚本调用了该/usr/bin/systemd-tmpfiles，修改了/run/ceph的权限，而/var/run是软链到/run的，最终导致了服务异常

rpm -q --scripts systemd:
...
systemctl start systemd-udevd.service >/dev/null 2>&1 || :
udevadm hwdb --update >/dev/null 2>&1 || :
journalctl --update-catalog >/dev/null 2>&1 || :
systemd-tmpfiles --create >/dev/null 2>&1 || :
...

风险屏蔽

临时修改/usr/lib/tmpfiles.d/ceph-common.conf 文件的内容为：

d /run/ceph 0777 ceph ceph -

蝴蝶效应

遇到问题要努力去解决而不能轻易放过，不然，它会出其不意给你一棒子~

关注笔者

专注笔者公众号，阅读更多干货文章：）