linux-kernel - Re: [PATCH] vfs: hard-ban creating files with control characters in the name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 9 Oct 2017 09:03:07 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     "J. Bruce Fields" <bfields@...ldses.org>,
        Theodore Ts'o <tytso@....edu>,
        Adam Borowski <kilobyte@...band.pl>,
        Al Viro <viro@...IV.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in
 the name

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@...morbit.com