Re: Implement C11 annex K?

[Rich Felker <dalias at libc dot org>]

On Thu, Aug 21, 2014 at 07:32:40PM -0700, Paul Eggert wrote:
> David A. Wheeler wrote:
> 
> >I'd like to convince you to think about *risk*.
> 
> I had already thought about it.  There's no evidence that using
> strlcpy reduces risk significantly, compared to spending an
> equivalent amount of effort using standard alternatives.  If
> anything, the little evidence we've seen indicates the contrary.
> 
> Most of your email was about *style*, not about *risk*.  Style
> arguments are a recipe for endless dispute, which I'd rather avoid;
> so I'll let you have the last word on style preferences.  Going onto
> the technical points:

I agree totally that style arguments are a dead-end, but can we focus
on the facts (cited in the linked email from Theo) about how many
programs are using strlcpy/strlcat, and providing their own (high
risk) when the system doesn't provide one? This is the one situation
where adding strlcpy/strlcat to glibc woukd make an immediate
difference to security: programs which only define their own version
when the system lacks it would immediately get a safe version.

For other programs which are unconditionally defining their own
version, there would be no immediate effect, but it's plausible that
they would gradually transition to using the system one when it's
available.

> >>>auth.c:486:
> >>>  strlcpy(buf, cp, sizeof(buf));
> >>>  ... So.. do you really believe that MAXPATHLEN really is the max length?
> >>
> 
> >>... this use of strlcpy has undefined behavior ...
> >
> >I don't think so.  strlcpy is required to copy the source left-to-right
> 
> The OpenBSD man page for strlcpy disagrees with you; see <http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/strlcpy.3>,
> which says "If the src and dst strings overlap, the behavior is
> undefined."  If strlcpy were standardized no doubt the same language
> would apply, as it's de rigueur for the string functions.

I'm actually somewhat surprised OpenBSD specified any aspect of the
function, except passing an invalid pointer or lying about the buffer
size, to yield undefined behavior. Without looking at the man page I
thought it was more likely they might have just overlooked this issue,
if they hadn't explicitly defined the function to check for it and
either support it or consider it a reportable error.

> For the other three calls to strlcpy, you raised only style-based
> objections.
> 
> So, on a technical basis we have the same results as before: of the
> five strlcpy calls you brought up, one call can have undefined
> behavior, one call does silent truncation, and the other three do
> not fix any bugs compared to using standard routines.
> 
> To be honest, I was surprised by these results: I didn't think
> strlcpy would be this strikingly bad.

:-)

Rich