Linux之父林纳斯·托瓦兹批评大小写不敏感功能这事儿。林纳斯在邮件列表里可没客气，狠狠批评了这个功能，说它有安全风险，还觉得这是设计上的大错特错。
- 林纳斯批评的重点
- 设计错得离谱
林纳斯直接就点明了，大小写不敏感功能从设计开始就不该搞出来。他觉得这问题可不是测试没做好，而是这功能的根本思路就有毛病，结果安全机制都能被绕过去，而且开发者还把这错当成个“优点”，这可不对。
-
安全风险的情况
-
不可打印字符的隐患：文件系统有时候会忽略文件名里那些看不见的字符，像控制字符或者特殊符号啥的。比如说，有人恶意弄个文件名 file.txt\x00恶意代码 ，结果文件系统可能就把它错当成正常的 file.txt 了。这可就麻烦了，用户程序检查文件名是不是符合要求的时候就被蒙骗过去，攻击者就能利用这个执行恶意操作。
- Unicode字符的乌龙：有些Unicode编码不一样的字符，像 ❤ 和 ❤️ ，在大小写不敏感的比较里可能会被当成一样的，可实际上它们看着或者意思上是有差别的。这样一来，攻击者就能弄些特殊的Unicode文件名绕过安全验证，搞出那种看着合法，实际有恶意内容的文件。
- 对开发者的看法
林纳斯挺生气地说，开发者把这个设计上的毛病当成“特性”，就为了兼容Windows的文件命名习惯。但这么一搞，Linux系统的安全性和设计原则都被破坏得够呛。
- 相关技术例子
- 不可打印字符的漏洞例子
比如说有个安全程序在检查文件名是不是 config.txt ，结果攻击者弄了个 config.txt\x00恶意代码 的文件。在大小写不敏感的文件系统里，这个文件就可能被错认成 config.txt ，程序就以为是合法文件，然后恶意内容就可能被执行了。
- Unicode字符冲突例子
Unicode里有些字符看着差不多，像 A 和 А ，后面这个是西里尔字母。要是文件系统把它们当成一样的，攻击者就能搞事了。比如说，有个合法文件叫 /etc/secret.conf ，攻击者弄个 /etc/secret.соnf （这里用西里尔字母的 с 代替了 c ），文件系统可能就把它俩当成同一个文件，安全检查就这么被绕过了。
- 这事儿的影响和争议
- 社区的反应
林纳斯这一批评，在开源社区可掀起了大讨论。有人支持他，觉得他把一直被忽略的安全隐患给揪出来了，得重新想想大小写不敏感功能到底有没有必要。但也有人反对，说这个功能在和Windows或者macOS文件系统兼容的时候，像跨平台协作的场景里，还是挺有用的。
- 实际应用的应对
有些开发者通过一些配置，像MySQL的 lower_case_table_names 参数，或者用Beyond Compare这样的工具来想办法缓解这个问题。可林纳斯觉得这些都是临时打补丁的办法，没办法从根本上解决设计的缺陷。
- 林纳斯为啥这么认为
- 安全比兼容重要：Linux设计讲究“明明白白比模模糊糊好”，大小写不敏感功能让文件名的唯一性变得模糊，把这个原则给破坏了。
- Unicode太复杂：在Unicode里，大小写转换可不是简单换一下就行，得处理好多变体和不同地区的差异，想要做出又安全又全面的大小写不敏感功能，几乎是不可能的事儿。
- 没吸取教训：以前像Windows那种路径遍历攻击的漏洞已经出现过好多次了，可文件系统开发者还是没从这些事儿里吸取教训。
- 之后可能咋做
- 社区行动：开发者可能会重新研究大小写不敏感功能到底咋实现，或者限制它默认开启的范围。
- 给用户的建议：要是在服务器、容器这些对安全要求高的环境里，最好别开大小写不敏感的文件系统。要是涉及跨平台文件操作，像在Windows和Linux之间同步文件，可以手动重命名，或者用Beyond Compare这种工具帮忙预处理一下。
林纳斯批评这事儿，其实就是文件系统设计里兼容性和安全性闹矛盾了。虽然大小写不敏感功能在有些场景下用着方便，可它带来的潜在风险可比好处大多了。这一争论说不定能让Linux社区重新审视文件系统设计，让安全性更强，漏洞更少。
网友评论