Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030915AbbD1TsQ (ORCPT ); Tue, 28 Apr 2015 15:48:16 -0400 Received: from mail-am1on0077.outbound.protection.outlook.com ([157.56.112.77]:24913 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030658AbbD1TsN (ORCPT ); Tue, 28 Apr 2015 15:48:13 -0400 Authentication-Results: spectrumdigital.se; dkim=none (message not signed) header.d=none; Message-ID: <553FE3F0.4060803@ezchip.com> Date: Tue, 28 Apr 2015 15:48:00 -0400 From: Chris Metcalf User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linus Torvalds , Al Viro CC: Fabian Frederick , Linux Kernel Mailing List , Randy Dunlap , Rickard Strandqvist Subject: Re: revert "fs/befs/linuxvfs.c: replace strncpy by strlcpy" References: <20150428034859.GI889@ZenIV.linux.org.uk> <1363736428.511175.1430199310500.open-xchange@webmail.nmp.proximus.be> <20150428160523.GJ889@ZenIV.linux.org.uk> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: BN3PR09CA0014.namprd09.prod.outlook.com (25.160.111.152) To VI1PR02MB0784.eurprd02.prod.outlook.com (25.162.14.146) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0784; X-Forefront-Antispam-Report: BMV:1;SFV:NSPM;SFS:(10009020)(6009001)(6049001)(377454003)(51704005)(24454002)(479174004)(93886004)(4001350100001)(83506001)(87976001)(59896002)(50466002)(5001770100001)(86362001)(19580395003)(19580405001)(33656002)(122386002)(40100003)(2950100001)(64126003)(62966003)(77156002)(23676002)(46102003)(65816999)(92566002)(15975445007)(77096005)(66066001)(54356999)(42186005)(87266999)(47776003)(50986999)(36756003)(65956001)(76176999)(65806001)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR02MB0784;H:[10.7.0.41];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006)(3002001);SRVR:VI1PR02MB0784;BCL:0;PCL:0;RULEID:;SRVR:VI1PR02MB0784; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 19:48:08.9670 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB0784 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3006 Lines: 66 On 04/28/2015 12:42 PM, Linus Torvalds wrote: > On Tue, Apr 28, 2015 at 9:05 AM, Al Viro wrote: >> >> Unfortunately, we _can't_ make strlcpy() never look past src + size - 1 - >> not without changing its semantics. > > Yeah, strlcpy is actually nasty. I don't understand why people like it > so much. It's a crap interface, and completely unsuitable for > untrusted sources because of the overrun issue. FWIW, I wanted to deal with some strncpy/strlcpy API issues last year and just put a "strscpy()" function in arch/tile/gxio/mpipe.c, with a comment saying it might be worth making it global at a later date, but at the time only the reviewers seemed interested in making it happen, so I let that possibility die on the vine. I argue that truncated strings are often pretty nasty, so you don't want to just silently say "Sure, I made it fit!" but instead make that be a failure case. In principle you could keep the return code of my proposed strscpy() and still do the truncated-string copy, but I think it's a mistake in almost every case, and if you really want that semantics, you should be forced to use something harder (e.g. some combination of explicit strlen and memcpy) so it's clear you know what you're doing. commit bceb7efa6a7e656bfaa67b6f54925e7db75bcd52 Author: Chris Metcalf Date: Tue Sep 2 16:25:22 2014 -0400 tile gxio: use better string copy primitive Both strncpy and strlcpy suffer from the fact that they do partial copies of strings into the destination when the target buffer is too small. This is frequently pointless since an overflow of the target buffer may make the result invalid. strncpy() makes it relatively hard to even detect the error condition, and with strlcpy() you have to duplicate the buffer size parameter to test to see if the result exceeds it. By returning zero in the failure case, we both make testing for it easy, and by simply not copying anything in that case, we make it mandatory for callers to test the error code. To catch lazy programmers who don't check, we also place a NUL at the start of the destination buffer (if there is space) to ensure that the result is an invalid string. At some point it may make sense to promote strscpy() to a global platform-independent function, but other than the reviewers, no one was interested on LKML, so for now leave the strscpy() function as file-static. Reviewed-by: Randy Dunlap Reviewed-by: Rickard Strandqvist Signed-off-by: Chris Metcalf -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/