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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html