Re: strncpy is not a safe version of strcpy
От | Kevin Grittner |
---|---|
Тема | Re: strncpy is not a safe version of strcpy |
Дата | |
Msg-id | 1407936691.21837.YahooMailNeo@web122301.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: strncpy is not a safe version of strcpy (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: strncpy is not a safe version of strcpy
Re: strncpy is not a safe version of strcpy |
Список | pgsql-hackers |
David Rowley <dgrowleyml@gmail.com> wrote: > I had a quick look at the usages of strncpy in master tonight and > I've really just picked out the obviously broken ones for now. > The other ones, on first look, either look safe, or require some > more analysis to see what's actually done with the string. > > Does anyone disagree with the 2 changes in the attached? I am concerned that failure to check for truncation could allow deletion of unexpected files or directories. While this is probably not as dangerous as *executing* unexpected files, it seems potentially problematic. At the very least, a code comment explaining why calling unlink on something which is not what appears to be expected is not a problem there. Some might consider it overkill, but I tend to draw a pretty hard line on deleting or executing random files, even if the odds seem to be that the mangled name won't find a match. Granted, those problems exist now, but without checking for truncation it seems to me that we're just deleting *different* incorrect filenames, not really fixing the problem. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: