问题描述
我了解 strlcpy 和 strlcat 被设计为 strncpy 和 strncat 的安全替代品.但是，有些人仍然认为他们不安全，只会导致不同类型的问题.
I understand that strlcpy and strlcat were designed as secure replacements for strncpy and strncat. However, some people are still of the opinion that they are insecure, and simply cause a different type of problem.
有人可以举例说明如何使用 strlcpy 或 strlcat(即 always null 终止其字符串的函数)可以导致安全性问题?
Can someone give an example of how using strlcpy or strlcat (i.e. a function that always null terminates its strings) can lead to security problems?
Ulrich Drepper 和 James Antill 表示这是真的，但从未提供示例或阐明这一点.
Ulrich Drepper and James Antill state this is true, but never provide examples or clarify this point.
推荐答案
首先，strlcpy 从未打算作为 strncpy(和 strncpy 从未打算作为 strcpy 的安全版本).这两个功能完全不相关.strncpy 是一个与 C 字符串(即以空字符结尾的字符串)完全没有关系的函数.它的名称中有 str... 前缀的事实只是一个历史错误.strncpy 的历史和目的是众所周知且有据可查的.这是一个为处理某些历史版本的 Unix 文件系统中使用的所谓固定宽度"字符串(而不是 C 字符串)而创建的函数.今天的一些程序员对其名称感到困惑，并假设 strncpy 以某种方式应该作为有限长度的 C 字符串复制函数(strcpy 的安全"兄弟)，这实际上完全是胡说八道，并导致糟糕的编程实践.当前形式的 C 标准库没有任何用于有限长度 C 字符串复制的功能.这就是 strlcpy 适合的地方.strlcpy 确实是为使用 C 字符串而创建的真正的有限长度复制函数.strlcpy 正确地完成了有限长度复制函数应该做的所有事情.唯一可以针对它的批评是，遗憾的是，它不标准.
Firstly, strlcpy has never been intended as a secure version of strncpy (and strncpy has never been intended as a secure version of strcpy). These two functions are totally unrelated. strncpy is a function that has no relation to C-strings (i.e. null-terminated strings) at all. The fact that it has the str... prefix in its name is just a historical blunder. The history and purpose of strncpy is well-known and well-documented. This is a function created for working with so called "fixed width" strings (not with C-strings) used in some historical versions of Unix file system. Some programmers today get confused by its name and assume that strncpy is somehow supposed to serve as limited-length C-string copying function (a "secure" sibling of strcpy), which in reality is complete nonsense and leads to bad programming practice. C standard library in its current form has no function for limited-length C-string copying whatsoever. This is where strlcpy fits in. strlcpy is indeed a true limited-length copying function created for working with C-strings. strlcpy correctly does everything a limited-length copying function should do. The only criticism one can aim at it is that it is, regretfully, not standard.
其次，另一方面，strncat 确实是一个与 C 字符串一起工作并执行有限长度连接的函数(它确实是 strcat).为了正确使用这个函数，程序员必须特别小心，因为这个函数接受的大小参数实际上并不是接收结果的缓冲区的大小，而是其剩余部分的大小(还有终止符被隐式计算).这可能会令人困惑，因为为了将该大小与缓冲区的大小联系起来，程序员必须记住执行一些额外的计算，这通常用于批评 strncat.strlcat 负责处理这些问题，更改接口以便不需要额外的计算(至少在调用代码中是这样).同样，我看到有人可以批评这一点的唯一依据是该功能不标准.此外，由于基于重新扫描的字符串连接概念的可用性有限，您在专业代码中不会经常看到 strcat 组中的函数.
Secondly, strncat on the other hand, is indeed a function that works with C-strings and performs a limited-length concatenation (it is indeed a "secure" sibling of strcat). In order to use this function properly the programmer has to take some special care, since the size parameter this function accepts is not really the size of the buffer that receives the result, but rather the size of its remaining part (also, the terminator character is counted implicitly). This could be confusing, since in order to tie that size to the size of the buffer, programmer has to remember to perform some additional calculations, which is often used to criticize the strncat. strlcat takes care of these issues, changing the interface so that no extra calculations are necessary (at least in the calling code). Again, the only basis I see one can criticise this on is that the function is not standard. Also, functions from strcat group is something you won't see in professional code very often due to the limited usability of the very idea of rescan-based string concatenation.
至于这些功能如何导致安全问题......他们根本不能.它们导致安全问题的程度不会超过 C 语言本身导致安全问题"的程度.你看，在很长一段时间里，有一种强烈的情绪，即 C++ 语言必须朝着发展成某种奇怪的 Java 风格的方向发展.这种情绪有时也会蔓延到 C 语言领域，导致对 C 语言特性和 C 标准库特性的无知和强行批评.我怀疑在这种情况下我们也可能会遇到类似的事情，尽管我当然希望事情没有那么糟糕.
As for how these functions can lead to security problems... They simply can't. They can't lead to security problems in any greater degree than the C language itself can "lead to security problems". You see, for quite a while there was a strong sentiment out there that C++ language has to move in the direction of developing into some weird flavor of Java. This sentiment sometimes spills into the domain of C language as well, resulting in rather clueless and forced criticism of C language features and the features of C standard library. I suspect that we might be dealing with something like that in this case as well, although I surely hope things are not really that bad.
这篇关于为什么 strlcpy 和 strlcat 被认为是不安全的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！