关注飞总聊IT，了解IT行业的方方面面。
今天互联网上的大新闻，轮到了阿里云盘。
阿里云盘上，只要在相册里创建个文件夹，然后选择分类图片，就可以看到其他用户云盘里面的照片了。
这事情有点吓人。
所以阿里云盘开始紧急热修复。
做法就是赶紧把图片的浏览整体关停了。
所以现在虽然用户还能创建文件夹，文件夹里还有其他人云盘的照片， 但是所有照片已经处于不可预料状态了。
按照live site incident的处理方式，首先应该是stop bleeding，然后才去解决实际的bug。
要是问题确实严重了，那就只能先一刀切停止服务了。这也没毛病。
但是话说回来了，阿里云盘的这个bug是真的很严重。
你要问我到底是什么导致了这样的bug呢？
我猜这可能不是bug，是系统设计的问题。
云盘大概率就是所有用户的文件都放在了一起。
然后metadata上面有哪些文件属于哪些用户。
每个人打开云盘的时候后台就查询这个用户对应的文件。
然后筛选文件类型是图片的。
结果不知道什么原因，userid拿不到或者为空的时候，系统就自动列出了所有的文件。
然后，这个bug就这样出现了。
当然这是我脑补的。
因为正常来说，如果每个用户有自己的token，然后数据是用了自己的token对应的key进行加密的，那么就绝对不会存在着其他人的文件被自己访问的问题。
因为加密的文件没有对应的key是无法解密的。
所以，我们首先就可以排除掉，存在云盘里面的文件，是按照每个用户进行了加密存储。
但是通常来说，我觉得云盘提供者，是应该进行加密保存才对。
阿里云盘上面可以看到所有人的照片，我们只能认为在文件data层面，完全没有根据每个用户单独进行加密存储。
所有的文件都是明文存储的，这才是这种泄露存在的基础。
那么，接下来，就是每个文件的metadata上应该有个owner的字段，有个type的字段。
不管什么原因，用户在新建的文件夹里面type选了图片，系统somehow就完全忽略了owner，直接问下面的存储系统返回所有“type==图片”的文件。
然后，这个bug就出来了。
只有这样才能解释得通，到底底层发生了什么？
但是对我辈数据库用户来说，这种样子实现的所谓访问控制，给我感觉计算机应该是不是体育老师教的，就是语文老师教的。
云盘的访问控制，能够实现成这个样子，导致如此严重的问题出现，你说我能说什么呢？
这个bug出了以后，你要问我，我是真的不知道阿里云盘的访问控制是不是值得信任了？
最低底限，我完全无法信任阿里云盘在访问控制上的实现。
我希望阿里云盘团队可以如实的公布是什么导致这个bug的。
不然的话，我对这个产品的访问控制一丁点的信任都没有，我建议在阿里云盘解释清楚之前，我的粉丝们千万别在阿里云盘上存任何敏感信息。
想和飞总单独提问交流，以及飞总的朋友们一起进步的可以订阅飞总知识星球：
