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
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 |