From: Guenter Roeck <linux@roeck-us.net>
To: Tyler Hicks <tyhicks@canonical.com>
Cc: ecryptfs@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: ecryptfs problems with encrypted/ unencrypted file names
Date: Sat, 20 Jan 2018 15:55:54 -0800 [thread overview]
Message-ID: <5765d47f-81a1-07d8-0a85-6d34b7a770bd@roeck-us.net> (raw)
Hi,
Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name")
was supposed to fix a situation where two files with the same name and same inode could
be created in ecryptfs. One of those files had an encrypted file name, the other file
name was unencrypted.
The impact of 88ae4ab9802e is that a mix of encrypted and unencrypted file names
is now no longer possible, or at least presumably that was the idea. However,
that is not the case. The only difference I can see is that it is now even easier
to create a situation where two files with the same name coexist (one encrypted
and the other not encrypted). In practice, this looks like the following
(files created with v4.14.12).
ecryptfs mounted with file name encryption enabled:
$ ls -li
total 48
5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile
5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile
5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2
5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2
$ grep . *
myfile:encrypted
myfile:encrypted
myfile2:encrypted
myfile2:encrypted
$ ls -li
total 48
5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVun.BU8Zu5-njbcIPoApxk7-E--
5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVunt0fda7t9YCtJ70cm911yZ---
5252817 -rw-rw-r-- 1 groeck groeck 12 Jan 20 12:52 myfile
5252827 -rw-rw-r-- 1 groeck groeck 12 Jan 20 15:37 myfile2
$ grep . *
ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVun.BU8Zu5-njbcIPoApxk7-E--:encrypted
ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVunt0fda7t9YCtJ70cm911yZ---:encrypted
myfile:unencrypted
myfile2:unencrypted
On top of that, if I create a file with file name encryption disabled, then remount with file
name encryption enabled, I see the following:
$ ls -li
ls: cannot access 'myfile3': No such file or directory
total 48
5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile
5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile
5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2
5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2
? -????????? ? ? ? ? ? myfile3
Pre-88ae4ab9802e, the file system had to be mounted with encrypted file names first to create
a file, then the same had to be repeated after mounting with unencrypted file names. Now the
duplicate files can be create both ways (unencrypted _or_ encrypted first).
What I fail to see is how the current code is better than before. I can only see downsides
- when mounted with encrypted file names, it is no longer possible to access files with
unencrypted names, _and_ it is even easier than before to create duplicate names.
Am I missing something ?
Thanks,
Guenter
reply other threads:[~2018-01-20 23:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=5765d47f-81a1-07d8-0a85-6d34b7a770bd@roeck-us.net \
--to=linux@roeck-us.net \
--cc=ecryptfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tyhicks@canonical.com \
--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 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 read-only IMAP folder(s) and NNTP newsgroup(s).