From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753082AbcDZUSD (ORCPT ); Tue, 26 Apr 2016 16:18:03 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:60983 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751999AbcDZUSB (ORCPT ); Tue, 26 Apr 2016 16:18:01 -0400 Date: Tue, 26 Apr 2016 21:17:57 +0100 From: Al Viro To: Valdis.Kletnieks@vt.edu Cc: Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] a corner case of open(2) Message-ID: <20160426201757.GR25498@ZenIV.linux.org.uk> References: <20160426175538.GO25498@ZenIV.linux.org.uk> <89187.1461696097@turing-police.cc.vt.edu> <20160426190248.GQ25498@ZenIV.linux.org.uk> <92598.1461698716@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <92598.1461698716@turing-police.cc.vt.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 26, 2016 at 03:25:16PM -0400, Valdis.Kletnieks@vt.edu wrote: > Gaah.. I lost a few words in there - /bin/ls is *expecting* to operate on > a directory, so to calls getdents. I meant some generic program that > opened a directory in error, and was expecting to act on "stream of bytes" > > > We also do not allow opening directories for *write*, and in that case EISDIR > > is the right error (and we do return it). > > OK, that and ftruncate() are about the only ways to cause trouble with a > directory opened by accident... ftruncate() requires the file to be opened for write (which already excludes directories) *and* it requires the file to be a regular one (which is redundant in case of directories, but e.g. a block device can be opened for write and ftruncate would still fail on that). EINVAL in both cases. truncate() for directories should fail with EISDIR (see vfs_truncate()); for anything that is neither directory nor regular - EINVAL (same place). O_TRUNC ends up failing with EISDIR on directories - see /* O_TRUNC implies we need access checks for write permissions */ if (flags & O_TRUNC) acc_mode |= MAY_WRITE; in build_open_flags() and aforementioned bit in may_open(). POSIX is bloody vague on that topic, but that's the common behaviour since 4.3BSD has fixed an fs-corrupting bug in the original implementation (4.2BSD allowed open(directory, O_TRUNC), which both succeeded *and* truncated the damn thing to zero, to great joy of fsck). Note that v7 didn't have O_TRUNC at all - creat(2) was the only way to get it and that opened the sucker r/w, so the usual rules re "no opening directories for write" applied. When O_TRUNC had been introduced, initially they'd missed the possibility of somebody passing it to read-only open() and the need to reject those for directories same as open for write.