lists.openwall.net   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  linux-cve-announce  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:	Fri, 1 Apr 2016 02:21:21 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Biggers <ebiggers3@...il.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
	jaegeuk@...nel.org, mhalcrow@...gle.com
Subject: Re: Legal characters in encrypted fscrypto (f2fs/ext4) filename?

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
			       
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists