Re: strncpy is not a safe version of strcpy

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: strncpy is not a safe version of strcpy
Дата
Msg-id 20131115145604.GA5489@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: strncpy is not a safe version of strcpy  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: strncpy is not a safe version of strcpy  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Proof of concept: standalone backend with full FE/BE protocol
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: strncpy is not a safe version of strcpy