From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753234AbdJHWEb (ORCPT ); Sun, 8 Oct 2017 18:04:31 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:64064 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214AbdJHWE3 (ORCPT ); Sun, 8 Oct 2017 18:04:29 -0400 Date: Mon, 9 Oct 2017 09:03:07 +1100 From: Dave Chinner To: Matthew Wilcox Cc: "J. Bruce Fields" , "Theodore Ts'o" , Adam Borowski , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in the name Message-ID: <20171008220307.GW15067@dastard> References: <20171003005042.16470-1-kilobyte@angband.pl> <20171003020724.GH21978@ZenIV.linux.org.uk> <20171003164012.r4qnn5cr5kzmnft6@thunk.org> <20171003173215.axcwmd4ynmvgkyym@angband.pl> <20171003185852.2o7w4tst6q7xchfe@thunk.org> <20171005161619.GA16482@fieldses.org> <20171006020942.GS15067@dastard> <20171006145701.GB18373@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171006145701.GB18373@bombadil.infradead.org> 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 Fri, Oct 06, 2017 at 07:57:01AM -0700, Matthew Wilcox wrote: > On Fri, Oct 06, 2017 at 01:09:42PM +1100, Dave Chinner wrote: > > On Thu, Oct 05, 2017 at 12:16:19PM -0400, J. Bruce Fields wrote: > > > This kind of restriction sounds more like a permanent feature of the > > > filesystem--something you'd set at mkfs time. > > > > > > We already have filesystems with these kinds of restrictions, don't we? > > > > In general, no. Filename storage typically defined in the > > filesystem on-disk formats as an opaque string of bytes - the > > filesystem has no business parsing them to determine validity of the > > bytes. Think encrypted filenames and the like - control characters > > in the on-disk format are most definitely necessary and therefore > > must be legal. > > Umm. But filenames still can't have / or \0 in them, so your encryption > already has to avoid at least two special characters. Filesystems can have those characters on disk without any problems. Most filesytsems do not null terminate dirents on disk - instead they keep a dirent length on disk to determine the length of the entry. "Opaque" means null is a valid character, not an "end of string" delimiter. Keep in mind that "/" is an OS dependent special character - other OS use different directory delimiters so have a different set of "special characters". This reinforces the fact that it is not the filesystem's job to police what is stored on disk - the filesysetm is just a GIGO filename storage mechanism - you get out exactly what you put in... > I agree with your main point though; there is no advantage to doing this > in each individual filesystem. Yup, especially when we consider filesystems that get mounted and written by different OS and independent filesystem implementations.... Cheers, Dave. -- Dave Chinner david@fromorbit.com