| |||||||||||||
Still no strlcpy and friendsStill no strlcpy and friendsPosted Mar 22, 2012 22:12 UTC (Thu) by tjc (subscriber, #137)In reply to: Still no strlcpy and friends by mgedmin Parent article: GNU libc 2.15 released
sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html sources.redhat.com/ml/libc-alpha/2000-08/msg00061.html As usually, the motive behind Debian's switch to EGLIBC is in evidence here.
(Log in to post comments)
Still no strlcpy and friends Posted Mar 23, 2012 6:47 UTC (Fri) by smurf (subscriber, #17840) [Link]
> switch to eglibc
… which doesn't help at all in this case, since eglibc decided to stay binary compatible to glibc and thus doesn't have strlcpy either.
Anyway, I reject Drepper's argument that this facilitates path truncation attacks. Sure it does, but the alternative (programs running off into la-la land because a string didn't get NUL-terminated) is much worse.
Still no strlcpy and friends Posted Mar 23, 2012 9:03 UTC (Fri) by khim (subscriber, #9252) [Link] Anyway, I reject Drepper's argument that this facilitates path truncation attacks. Sure it does, but the alternative (programs running off into la-la land because a string didn't get NUL-terminated) is much worse. I'm not so sure. If program runs off into la-la land then it tends to crash which will be noticed, if program just rejects your input it's less visible problem. This means that program with incorrect handling of strings based on strlcpy is worse in the presence of skilled administrator and about the same in the absence of such administrator. The net worth is probably still negative.
Still no strlcpy and friends Posted Mar 23, 2012 13:18 UTC (Fri) by NAR (subscriber, #1313) [Link] I'm not so sure. If program runs off into la-la land then it tends to crash which will be noticed, if program just rejects your input it's less visible problem.This time I'm not sure :-) The crash will be noticed on one system. The exploit created based on that crash might break the other system without crashing anything there...
Still no strlcpy and friends Posted Mar 23, 2012 9:47 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Your use of the phrase /the alternative/ implies that you're dealing with the sort of programmers who, when they discover that there's no built-in standard library function which does what they need, just do something else and tell the end user too bad it can't work the way you asked.
The _real_ alternative is for programmers to think about what they actually want to do with outliers and then do it. What if the GET request is 40kbytes long? Should they truncate it until it fits in the maximum path size? That seems wrong. Maybe they should overwrite the stack? No, that seems wrong too. Aha! They should report an HTTP error to the remote client saying that request is stupid.
I'm always much happier to see
Than an uncommented line which calls some standard function and doesn't do anything with the return value or errors.
New standard library functions should, on the whole, reflect good existing practice. It's not clear that strlcpy-like functions in existing code are good practice, they're often just laziness. The C library already has more than enough of that.
Still no strlcpy and friends Posted Mar 23, 2012 16:40 UTC (Fri) by tjc (subscriber, #137) [Link]
> … which doesn't help at all in this case, since eglibc decided to stay binary compatible to glibc and thus doesn't have strlcpy either.
Actually, the reason for Debian switching to EGLIBC that I alluded to was so that they didn't have to deal with Drepper. It wasn't the only reason, but it was a factor.
Still no strlcpy and friends Posted Mar 25, 2012 1:51 UTC (Sun) by nix (subscriber, #2304) [Link]
I wonder how long it will be before they switch back? glibc development has really livened up recently (probably because drepper has left RH and isn't so involved anymore).
Still no strlcpy and friends Posted Mar 26, 2012 14:46 UTC (Mon) by cortana (subscriber, #24596) [Link]
eglibc is more of a branch than a fork, so it's not clear they really need to.
|
|||||||||||||