On Mon, Mar 04, 2002 at 03:27:30PM -0800, elf@buici.com wrote:
> > > > I am working at the moment on some port from openBSD to debian, and
> > > > discovered that they use this strlcpy|cat (security enhanced version
> > > > of strNcpy|cat). Does someone know if there are any plan or a place
> > > > to get those included in the standard version of the libc ?
> > >
> > > Get an impression:
> > >
> > > http://sources.redhat.com/ml/libc-alpha/2002-01/msg00001.html
> > > http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html
> >
> > Nice to see good old anti-Theoism influencing excuses to ignore code which
> > makes perfect sense.
>
> As long as there are no toungues in cheeks, you seem to think that
> strlcpy is better than strncpy.
I do. strncpy does not null-terminate its strings if the source string is
longer than the count you specify. This is sometimes welcome behavior,
but not often. In the cases that it is not welcome, which are the vast
majority, strlcpy does a better thing.
> > I don't know how these functions have any effect on security over the strn
> > functions except in the most indirect manner, but can anyone tell me what
> > the point of not copying a string past the end of the space allocated for
> > it is if the next time you attempt to use the newly copied string you run
> > right off the edge of the new array?
>
> Here is where I run afoul. It makes sense to me that these functions
> are much less interesting for any perceived security impact than for
> their potential to improve performance. What are you asking here
> about running off the end of an array?
char dest[6];
char src[] = "foobar";
strncpy (dest, src, sizeof (dest));
dest contains { 'f', 'o', 'o', 'b', 'a', 'r' } after this call. There is
no terminator. printf ("%s\n", dest) will result in foobaradf123rhv3...
and probably a segfault.
char dest[6];
char src[] = "foobar";
strlcpy (dest, src, sizeof (dest));
dest contains { 'f', 'o', 'o', 'b', 'a', '\0' } after this call. There is
now a terminator. printf ("%s\n", dest) will result in fooba and while
this is probably unintended, it won't segfault anything.
The strncpy may indirectly cause some potential security flaw, but it is
directly capible of doing anything but feeding your program garbage and
causing a read access violation.
> > But somehow, s/n/l/ in the function name is harder to read and the
> > function is "inefficient BSD crap".
>
> What do you mean here? Is it that strlcpy is less efficient than
> strncpy?
So say the glibc people in the threads referenced. If the implementation
is flawed, that should be fixed. The preconditions, postconditions, and
function declaration are a fine improvement, however.
Also, notice that strncpy returns a pointer to dest. This is almost never
used by anyone. I personally have never used it actually. strlcpy does
return a value, but returns instead the number of characters copied from
src. This too I use rarely, but whereas strncpy's return value has never
been even remotely useful to me, strlcpy's has upon occasion.
Also, since copying the string also calculates how long the string shall
be, this strlcpy is _more_ efficient than following the strncpy with a
strlen (dest), all other factors considered equal.
> > The only real controversy here is between the status quo and possibly
> > inflating Theo's ego further (if such could actually be accomplished
> > anyway.) In the meantime, most of my work (and a lot of other people's as
> > well) will continue to reinvent the wheel while the glibc maintainers
> > continue to cover their ears and hum REAL LOUD.
>
> Insinuating that glibc maintainers have neglected to include strlcpy.
> A valid point unless there is some presently unstated reason to leave
> these functions out.
The stated reasons that strl functions will not be included are:
- They promote bad or less readable code
- They are "inefficient BSD crap"
- They do not enhance security in any meaningful capacity
While I'm not likely to argue on the third point (except out of rampant
paranoia that it's possible that maybe you could get a printf to feed you
output that you as a user should not be able to see, maybe a passwd or
something?), the other two reasons are not really reasons - they're BSD
bashing. While I have tons of reasons to bash BSD, OpenBSD particularly,
the strl functions are not among them.
--
Joseph Carter <knghtbrd@bluecherry.net> Intelligent backside at large
<rebelpacket> hey, quick question, is there any way to speed up the
performance of uquake-x11?
<Deek> rebelpacket: If you want to accelerate it, throw it harder.
Attachment:
pgpi1r9fhTYTk.pgp
Description: PGP signature