风险：隐蔽权限修改致使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 -

蝴蝶效应

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

关注笔者

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