Re: strncpy is not a safe version of strcpy - Mailing list pgsql-hackers

From Andres Freund
Subject Re: strncpy is not a safe version of strcpy
Date
Msg-id 20131115145604.GA5489@awork2.anarazel.de
Whole thread Raw
In response to Re: strncpy is not a safe version of strcpy  (Stephen Frost <sfrost@snowman.net>)
Responses Re: strncpy is not a safe version of strcpy  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On 2013-11-15 09:53:24 -0500, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > FWIW, argv0 is pretty much guaranteed to be shorter than MAXPGPATH since
> > MAXPGPATH is the longest a path can be, and argv[0] is either the executable's
> > name (if executed via PATH) or the path to the executable.
> 
> Err, it's the longest that *we* think the path can be..  That's not the
> same as actually being the longest that a path can be, which depends on
> the filesystem and OS...  It's not hard to get past our 1024 limit:

Sure, there can be longer paths, but postgres don't support them. In a
*myriad* of places. It's just not worth spending code on it.

Just about any of the places that use MAXPGPATH are "vulnerable" or
produce confusing error messages if it's exceeded. And there are about
zero complaints about it.

> > Now, you could probably write a program to exeve() a binary with argv[0]
> > being longer, but in that case you can also just put garbage in there.
> 
> We shouldn't blow up in that case either, really.

Good luck.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Next
From: Stephen Frost
Date:
Subject: Re: strncpy is not a safe version of strcpy