Windows 对于其安装的不同文件系统是否具有相同的最大路径长度（目录条目名称）？
我想知道TCL 8.4中的特定漏洞是否影响Windows平台
该漏洞是：http://www .securityfocus.com/bid/15259/info 根据链接：
不同文件系统之间最大路径长度没有差异的操作系统不受此问题的影响
我在 Windows 上使用 TCL，想知道此漏洞是否会影响 Windows 上的 TCL 以及如何影响？
此外，人们如何在 Windows 上利用此漏洞？
谢谢
I have to know if a specific vulnerablity in TCL 8.4 affects Windows platform
The vulnerability is: http://www.securityfocus.com/bid/15259/info
As per the link:
Operating systems with no difference in the maximum path lengths among differing file systems are not affected by this issue
I am using TCL on windows and want to know if this vulnerablity affects TCL on windows and how ?
Further, how can a person exploit this vulnerability on Windows ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Windows 头文件将 MAX_PATH - 定义为 260 - 作为通常的最大路径大小。这并没有真正普遍应用。有多种方法可以绕过此限制，在这种情况下，有效路径限制是无限的。或 32,767 个字符。以较短者为准。
命名、文件、路径和命名空间有更多信息。
The windows header files define MAX_PATH - as 260 - as the usual maximum path size. This isn't really universally applied. There are a number of ways to bypass this limit, in which case the effective path limit is, well, unlimited. Or 32,767 characters. Whichever is shorter.
Naming, Files, Paths and Namespaces has more info.
虽然存在关于最大文件名和路径长度的常见约定，但某些文件系统驱动程序（或第三方文件系统实现）可能有自己的限制，该限制可能低于常用的限制。
While there exist common conventions regarding maximum file name and path length, certain file system drivers (or third-party file system implementations) might have their own limits which can be lower, than the commonly used ones.
该文章根本没有提到 Windows 上托管的系统对此的任何漏洞；要分配的标准建议缓冲区大小足以容纳任何合法文件名。对于 Tcl 来说尤其如此（Tk 不进行目录扫描，除非通过 Tcl 的接口）。
在 Windows 上利用该漏洞将会很困难（对于 Tcl 来说是不可能的，因为 Tcl 对缓冲区管理非常谨慎）。如果您使用的是其他平台，建议您切换到更高版本的Tcl；当前版本是8.4.19。 （实际上，建议您切换到 8.5 系列（当前为 8.5.9），因为 8.4 基本上已停产；该分支上可能还会有一个汇总版本，但错误修复现在仅针对关键问题提交到 8.4例如演示的安全问题或构建链问题。）
请注意，由于 Tcl 从未 分配缓冲区来直接保存整个路径，因此尚不清楚此类事情如何导致首先是一种利用。该文章确实指出，目前还没有出现此问题的实例。
That article does not mention any vulnerability of systems hosted on Windows to this at all; the standard recommended size of buffer to be allocated there is sufficiently long to hold any legal filename. This is specifically true for Tcl (Tk does not do directory scanning except via Tcl's interfaces).
Exploiting the vulnerability on Windows is going to be hard (and impossible with Tcl, which is very careful with buffer management). If you're on another platform, you are recommended to switch to a later patchlevel of Tcl; the current version is 8.4.19. (Actually, you're recommended to switch to the 8.5 series – currently 8.5.9 – as 8.4 as basically been EOLed; there will be maybe one more roll-up release on that branch but bugfixes are now only committed to 8.4 for critical things like demonstrated security issues or build-chain problems.)
Note that, since Tcl has never allocated buffers for holding a whole path directly anyway, it's not clear how this sort of thing could cause an exploit in the first place. The article does state that there is no instance of this issue in the wild.