agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Kevin Grittner <[email protected]>
To: David Rowley <[email protected]>
To: Noah Misch <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: strncpy is not a safe version of strcpy
Date: Wed, 13 Aug 2014 17:23:30 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAApHDvoKSa-2yjdSfoFk8bC8A4QGfFb3f5R3LETJ_h_-Of1dPg@mail.gmail.com>
<[email protected]>
<CAApHDvoQ6rNPTBWJrz7_hRVm32yhRZU7mb+=yYXJkYnxpOqw7A@mail.gmail.com>
<[email protected]>
<CAApHDvrCrKSrx3WJSxN2-9FQJGYZMWtz-Nz9c4PWEMTYW8sdQg@mail.gmail.com>
<[email protected]>
<CAApHDvp6YM9tSBCLZOrA-P5oAWjoN-dDU7200O7wERsiG=9EYA@mail.gmail.com>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
On 08/13/2014 04:31 PM, Kevin Grittner wrote:
> David Rowley <[email protected]> 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.
strlcpy is clearly better than strncpy here, but I wonder if we should
have yet another string copying function that throws an error instead of
truncating, if the buffer is too small. What you really want in these
cases is a "path too long" error.
- Heikki
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (32+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: strncpy is not a safe version of strcpy
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox