From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751395AbdJEQQV (ORCPT ); Thu, 5 Oct 2017 12:16:21 -0400 Received: from fieldses.org ([173.255.197.46]:58274 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751144AbdJEQQT (ORCPT ); Thu, 5 Oct 2017 12:16:19 -0400 Date: Thu, 5 Oct 2017 12:16:19 -0400 To: "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: <20171005161619.GA16482@fieldses.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171003185852.2o7w4tst6q7xchfe@thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 03, 2017 at 02:58:52PM -0400, Theodore Ts'o wrote: > The argument for making it be configurable is that if it does break > things in way we can't foresee, it's a lot easier to back it out. And > like what we've done with relatime, if the distro's all run with it as > the default for a couple of years, it then becomes easier to make the > case for making it be the default. I find it hard to believe that any general-purpose distro could turn on something like this without breaking a gazillion things for users. > > Discussing a configurable policy (perhaps here in vfs, perhaps as a LSM, a > > seccomp hack or even LD_PRELOAD) would be interesting, but for the above > > reason I'd want \n hard-banned. > > Perhaps doing this as an LSM makes the most amount of sense. That > makes it be configurable/optional, and I think the security folks will > be much more willing to accept the functionality, if we decide we > don't want to make it a core VFS restriction. Making this something you can turn on and off seems likely to create all sorts of surprises for users when filenames written under one kernel can't be read under another. 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? It'd seem trivial to add a "disallow weird characters on this superblock" flag to ext4. --b.