Legal characters in encrypted fscrypto (f2fs/ext4) filename?

Legal characters in encrypted fscrypto (f2fs/ext4) filename?

[Eric Biggers]

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+,

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+=

Which one is correct?

[1] https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg/preview?pref=2&pli=1#

Re: Legal characters in encrypted fscrypto (f2fs/ext4) filename?

[Theodore Ts'o]

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
			       

Re: Legal characters in encrypted fscrypto (f2fs/ext4) filename?

[Theodore Ts'o]

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