Re: strncpy is not a safe version of strcpy

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strncpy is not a safe version of strcpy
Date: 2013-11-15 14:56:04
Message-ID: 20131115145604.GA5489@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-11-15 09:53:24 -0500, Stephen Frost wrote:
> * Andres Freund (andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2013-11-15 14:57:16 Re: GIN improvements part2: fast scan
Previous Message Stephen Frost 2013-11-15 14:53:24 Re: strncpy is not a safe version of strcpy