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

From Kevin Grittner
Subject Re: strncpy is not a safe version of strcpy
Date
Msg-id 1407936691.21837.YahooMailNeo@web122301.mail.ne1.yahoo.com
Whole thread Raw
In response to Re: strncpy is not a safe version of strcpy  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: strncpy is not a safe version of strcpy
Re: strncpy is not a safe version of strcpy
List 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 by date:

Previous
From: "MauMau"
Date:
Subject: Re: proposal for 9.5: monitoring lock time for slow queries
Next
From: Alvaro Herrera
Date:
Subject: Re: ALTER TABLESPACE MOVE command tag tweak