All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Adam Borowski <kilobyte@angband.pl>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: hard-ban creating files with control characters in the name
Date: Fri, 6 Oct 2017 07:57:01 -0700	[thread overview]
Message-ID: <20171006145701.GB18373@bombadil.infradead.org> (raw)
In-Reply-To: <20171006020942.GS15067@dastard>

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.

I agree with your main point though; there is no advantage to doing this
in each individual filesystem.

  parent reply	other threads:[~2017-10-06 14:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03  0:50 [PATCH] vfs: hard-ban creating files with control characters in the name Adam Borowski
2017-10-03  2:07 ` Al Viro
2017-10-03  3:22   ` Adam Borowski
2017-10-05 10:07     ` Olivier Galibert
2017-10-06 14:54       ` Matthew Wilcox
2017-10-03 16:40   ` Theodore Ts'o
2017-10-03 17:32     ` Adam Borowski
2017-10-03 18:58       ` Theodore Ts'o
2017-10-03 19:12         ` Casey Schaufler
2017-10-05 16:16         ` J. Bruce Fields
2017-10-06  2:09           ` Dave Chinner
2017-10-06 14:38             ` J. Bruce Fields
2017-10-06 14:57             ` Matthew Wilcox [this message]
2017-10-06 20:00               ` Theodore Ts'o
2017-10-08 22:03               ` Dave Chinner
2017-10-05 13:47       ` Alan Cox
2017-10-05 12:07 Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171006145701.GB18373@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=bfields@fieldses.org \
    --cc=david@fromorbit.com \
    --cc=kilobyte@angband.pl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.