linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: mhalcrow@google.com, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, jaegeuk@kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: Legal characters in encrypted fscrypto (f2fs/ext4) filename?
Date: Fri, 1 Apr 2016 02:21:21 -0400	[thread overview]
Message-ID: <20160401062121.GC29897@thunk.org> (raw)
In-Reply-To: <20160401060018.GD1323@zzz>

On Fri, Apr 01, 2016 at 01:00:18AM -0500, Eric Biggers wrote:
> Hello,
> 
> While reviewing the new filesystem encryption code, I was confused by the
> intended set of legal characters in the printable form of an encrypted filename.
> 
> According to the actual code in fs/crypto/fname.c, the legal characters are:
> 
> 	a-zA-Z0-9+,

It's not really a question of "legality".  Rather, the base-64
encoding that we use is merely a presentation layer issue.  It's
really an implementation detail that does not affect the on-disk
encoding, and so in fact, it can be changed in different kernel
versions since the "encrypted filename" is essentially a cookie which
is presented to the user via readdir(), and which the user can then
send back to the kernel using, say, the unlink() system call.

It's changed over time to avoid potential confusion --- for example
the traditional base-64 encoding uses a-zA-Z0-9+/ --- but the use of
'/' causes problem because it's the pathname separator.

The fact that the design doc and comments are out of date is
unfortunate, but ultimately, it really doesn't matter.  

> Alternatively, according to the comment in the same file, the legal characters
> are actually:
> 
> 	a-zA-Z0-9+_
> 
> Still alternatively, according to the design document[1], the legal characters
> are actually:
> 
> 	a-zA-Z0-9+=

As I recall the equals sign could cause problems with shell scripts.
I don't remember the objection to the underscore character.

If you wanted to patch the kernel so that on your system, you used
a-ZA-Z0-9^@, you wouldn't break compatibility or interoperability.  So
there really isn't any such thing as "correct".

Cheers,

  	  		     	       - Ted
			       

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

      reply	other threads:[~2016-04-01  6:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01  6:00 Legal characters in encrypted fscrypto (f2fs/ext4) filename? Eric Biggers
2016-04-01  6:21 ` Theodore Ts'o [this message]

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=20160401062121.GC29897@thunk.org \
    --to=tytso@mit.edu \
    --cc=ebiggers3@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).