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

[Dave Chinner <david@fromorbit.com>]

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