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  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 <>
To:     Matthew Wilcox <>
Cc:     "J. Bruce Fields" <>,
        Theodore Ts'o <>,
        Adam Borowski <>,
        Al Viro <>,,
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


Dave Chinner

Powered by blists - more mailing lists