Bug 415681 - [RHEL5.2] ecryptfs mount options are poorly documented & confusing
[RHEL5.2] ecryptfs mount options are poorly documented & confusing
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ecryptfs-utils (Show other bugs)
5.2
All Linux
low Severity low
: ---
: ---
Assigned To: Karsten Hopp
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-07 09:47 EST by Jarod Wilson
Modified: 2008-08-26 06:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-26 06:55:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jarod Wilson 2007-12-07 09:47:53 EST
Description of problem:
If I try to specify all the mount options I'd like an ecryptfs overlay mount to
use so that the mount can be done by only asking for the passphrase, it seems
the options list gets so long that mount.ecryptfs just throws out the baby with
the bath water and goes for a fully interactive mount.

Version-Release number of selected component (if applicable):
ecryptfs-utils-30-2.el5

How reproducible:
1) create openssl key
2) mount -t ecryptfs -o
key=openssl:keyfile=/root/.ecryptfs/pki/openssl/key.pem:ecryptfs_cipher=twofish:ecryptfs_key_bytes=16:ecryptfs_passthrough=no:passthrough=no,context="system_u:object_r:tmp_t"
/secret /secret

I wind up getting prompted for key type, key file, cipher and passthrough
settings, all of which were on the command line.
Comment 1 Jarod Wilson 2007-12-07 09:49:33 EST
Nb: to date, I've *never* seen ecryptfs actually mount a volume without having
to select a cipher, despite passing it in on the cli.
Comment 2 Jarod Wilson 2007-12-07 10:03:44 EST
Oh, and to make it more interesting, the list of ciphers gets presented in
seemingly random different orders, which forces the user to carefully read the
list and choose the right number for the cipher they actually want. Also, the
default cipher is presented in its text form, which suggests one can input the
cipher by name. That doesn't actually work, you have to input the number from
the numbered list (which as I just noted, is a moving target from one invocation
to the next).
Comment 3 Jarod Wilson 2007-12-07 11:02:23 EST
Okay, so it seems that the ecryptfs mount helper (mount.ecryptfs) is actually
expecting slightly different options than the actual mount command is passing on
to kernel-space. The mount helper wants passthrough and cipher, but then passes
along ecryptfs_passthrough and ecryptfs_cipher. Of course, the documentation
doesn't mention this... And when you do give the mount helper the cipher option,
at least you don't get prompted for cipher anymore, but now your
cipher_key_bytes parameter disappears:

[root@xw4400-01 ~]# mount -t ecryptfs -o
key=openssl:keyfile=/root/.ecryptfs/pki/openssl/key.pem:cipher=twofish:ecryptfs_key_bytes=16:passthrough=no,context="system_u:object_r:tmp_t"
/secret /secretPassphrase: 
Attempting to mount with the following options:
  ecryptfs_cipher=twofish
  ecryptfs_sig=94733f578c4b75f6
Required mount option not provided: [ecryptfs_key_bytes=]
Invalid mount options; aborting. rc = [1]
Error mounting eCryptfs; rc = [-1]; strerr = [Operation not permitted]. Check
your system logs; visit <http://ecryptfs.sourceforge.net/ecryptfs-faq.html>.

[root@xw4400-01 ~]# mount -t ecryptfs -o
key=openssl:keyfile=/root/.ecryptfs/pki/openssl/key.pem:cipher=twofish:key_bytes=16:passthrough=no,context="system_u:object_r:tmp_t"
/secret /secret
Passphrase: 
Attempting to mount with the following options:
  ecryptfs_cipher=twofish
  ecryptfs_sig=94733f578c4b75f6
Required mount option not provided: [ecryptfs_key_bytes=]
Invalid mount options; aborting. rc = [1]
Error mounting eCryptfs; rc = [-1]; strerr = [Operation not permitted]. Check
your system logs; visit <http://ecryptfs.sourceforge.net/ecryptfs-faq.html>.
Comment 4 Eric Sandeen 2007-12-07 13:04:50 EST
Ok, so this doesn't have to do with the length of the string... Jarod is right,
that the mount helper expects a syntax as shown in
http://ecryptfs.sourceforge.net/README ("a BNF grammar") but uses those to
construct a different set of arguments for the actual mount, near as I can tell.

For example on Jarod's string:
mount -t ecryptfs -o
key=openssl:keyfile=/root/.ecryptfs/pki/openssl/key.pem:ecryptfs_cipher=twofish:ecryptfs_key_bytes=16:ecryptfs_passthrough=no:passthrough=no,context="system_u:object_r:tmp_t"
/secret /secret

ecryptfs_cipher and ecryptfs_passthrough, anc ecryptfs_key_length are not valid
when specified this way, but "cipher" and "passthrough" are.  There is no
analogous option for key length.

Honestly I think this is incredibly confusing, but...

The above README also says that "ecryptfs_key_bytes" is an option, but at least
the mount helper does NOT parse this.  However, if you pass it as a separate
option not to be parsed by the helper (i.e. with a comma, not a colon) like this:

# mount -t ecryptfs -o
key=openssl:keyfile=/root/.ecryptfs/pki/openssl/key.pem:passthrough=yes:cipher=aes,xattr,ecryptfs_key_bytes=16
 /root/secret3 /root/secret3
Passphrase: 
Attempting to mount with the following options:
  ecryptfs_xattr_metadata
  ecryptfs_passthrough
  ecryptfs_cipher=aes
  ecryptfs_sig=cf5dc7edf55afe25
Mounted eCryptfs

then ooh, look, it works! :)

(strangely it does not print out the key_bytes value above, but it is shown in
/etc/mtab, go figure)

A dose of accurate documentation would go a long way, as would adhering to the
rule of least surprise when parsing mount options.
Comment 5 Eric Sandeen 2007-12-07 15:26:11 EST
After talking w/ Mike about this I feel better.  :)  there is work to be done in
userspace to be sure, and I think cleaning up the docs to reflect usage intent
would go a long ways.  I'll look into it.

take-away message for this bug though is that only a few options are
key-specific and intended to go into the colon-delimited options; all other are
global and are the normal comma-delimited mount options.
Comment 6 Phil Knirsch 2008-04-28 08:57:02 EDT
Any news on the doc update here? I'd like to propose it for RHEL-5.3 if possible.

Thanks,

Read ya, Phil
Comment 7 Eric Sandeen 2008-04-28 09:02:40 EDT
I'll have to get up to date on this again :) and see how userspace & kernelspace
has evolved; I think it's in much better shape now but will give it a once-over.

Thanks,
-Eric

Note You need to log in before you can comment on or make changes to this bug.