近日在巡查时发现一台备份服务器上的文件的group和owner和源机器不一致
源机器：
-rw-r--r-- 1 root root 178261 Mar 27 2020 sample
备份机器：
-rw-r--r-- 1 500 500 178261 Mar 27 2020 sample
备份机是用rsync -a命令从源机器拉取文件进行的数据备份，按道理来说会保留文件在源机器上的owner和group，但从结果来看并非如此
一上来我先怀疑是rsync在chown的阶段出了问题，没能正确执行完成，于是手动执行rsync命令从源机器拉了一个文件试验，结果依然一样
好吧，进入喜闻乐见的解谜阶段
加上-vvvv参数看看rsync命令的执行细节
...
receiving incremental file list
uid 500() maps to 500
gid 500() maps to 500
...
[Receiver] i=1 1 sample mode=0100644 len=178,261 uid=500 gid=500 flags=0
...
set uid of .sample.gKDV2E from 0 to 500
set gid of .sample.gKDV2E from 0 to 500
renaming .sample.gKDV2E to sample
...
这里能看出来rsync的server端发过来的file list中，sample文件的uid和gid就是500。我眼花了不成？去源机器上用stat复查了一遍，文件的uid和gid确实是0
感觉有点诡异了，又经过了一番乱七八糟的尝试，不断排除，最终形成了这样一个场景：
在源机器上建了一个空目录，里面放了两个文件：
-rw-r--r-- 1 root root 178261 Mar 27 2020 sample
-rw-r--r-- 1 root root 178261 Mar 27 2020 sample2
其中sample是用cp命令拷贝过来的，sample2是用cp -a命令拷贝过来的
用rsync命令拉这个目录的结果是：
-rw-r--r-- 1 root root 178261 Mar 27 2020 sample
-rw-r--r-- 1 500 500 178261 Mar 27 2020 sample2
一个root/root，一个500/500……
这个局面感觉更加魔幻了，两个uid/gid一样的文件，用rsync拉过来之后，gid/uid变的不一样了
查到这有点没辙了，只好拉外援，小伙伴strace了一下cp -a命令，发现了一条重要线索：
...
getxattr(3, "user.rsync.%stat", NULL, 0) = 20
fgetxattr(3, "user.rsync.%stat", "100644 0,0 500:500", 20) = 20
fsetxattr(4, "user.rsync.%stat", "100644 0,0 500:500", 20, 0) = 0
...
这说明cp -a命令会把源文件的xattr（扩展属性）也复制到目标文件，而这个源文件的xattr中有一条：
user.rsync.%stat = "100644 0,0 500:500"
这属性名user.rsync.%stat，用膝盖想也知道是rsync程序写进去的，而属性值里记录的uid和gid刚好就是500。而源机器上的这个文件，恰恰也是其他机器用rsync命令推上来的
关于user.rsync.%stat，查到了如下说明：
This option --fake-super offers a way to back up privileged information without requiring root privileges. It works by adding special extended attributes such as user.rsync.%stat containing al this information. Of course, it still requires a destination file system that supports extended attributes.
再查一下源机器的rsyncd.conf，里面果然有一行fake super = yes
fake super这个flag，意思是让rsync daemon“模拟”super用户，这让rsync daemon以非root用户启动时，即便接收到了超出自己权限的文件，也能把文件的权限/owner/group等信息保存下来，具体怎么做到的呢，就是把上述属性写到文件的xattr里啦
好了，这下破案了，还原一下过程：
- 服务器A的rsync daemon以--fake-super参数启动，所以虽然A上rsync daemon本身就是以root用户启动的，但还是会采用fake-super的机制，把接收到的文件属性写到xattr里
- 某人从服务器B执行
rsync -a命令把一个文件推到A上，该文件的uid/gid是500:500 - 服务器A的rsync daemon接收文件，并把500/500写到了文件的xattr里，同时该文件在A上的owner和group都被设置成了root（因为rsync daemon是用root用户启动的）
- 服务器C通过
rsync -a命令从服务器A备份文件 - 服务器A的rsync daemon构建文件列表，在生成文件的owner/group时，并未直接读取该文件在本机上的owner/group
(root:root)，而是从xattr里读取出了该文件在服务器B上的原始owner/group(500:500) - 服务器C按照A传输过来的文件列表，把接收下来的文件的owner/group设置为了500:500
结案！
rsync这个程序真是不断的惊到我，细节之丰富，思想之缜密，叹为观止~
