Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932312Ab2HQXnZ (ORCPT ); Fri, 17 Aug 2012 19:43:25 -0400 Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]:35505 "EHLO ppsw-41.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755211Ab2HQXnR (ORCPT ); Fri, 17 Aug 2012 19:43:17 -0400 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Date: Sat, 18 Aug 2012 00:43:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jesper Juhl cc: linux-kernel@vger.kernel.org, Tony Finch Subject: Re: [PATCH] unifdef: set a secure umask before calling mkstemp() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 27 Jesper Juhl wrote: > In newer glibc's (versions > 2.06) reasonably secure permissions of > 0600 are used when creating a temporary file with mkstemp(). But for > older glibc's (versions <= 2.06) 0666 is used which is not secure. Thanks for your suggestion! I'm afraid I prefer not to make the change. Unifdef is only using mkstemp as a convenient way to open a file with a non-clashing name. It isn't trying to be secure, so it's OK just to rely on the user's umask. And I find it hard to care about a bug that was fixed 15 years ago. I'm also trying to reduce the unixisms in the program for portability reasons and this is the most awkward part :-/ Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. -- 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/