Red Hat Bugzilla – Bug 432961
passfile option for key=openssl doesn't work
Last modified: 2008-05-21 13:33:28 EDT
Description of problem: When I try to mount filesystem using key=openssl option and passfile option, mount helper fails and reports error. Version-Release number of selected component (if applicable): ecryptfs-utils-38-1.el5 linux kernel 2.6.18-79.el5 How reproducible: 100% running mount.ecryptfs with appropriate options Steps to Reproduce: as root do following: 1. create openssl key openssl genrsa -out mykey.pem -des3 -passout pass:secret 2. prepare file containing passphrase echo "passwd=secret" > passfile.txt 3. create mount point and mount filesystem mkdir .secret mount.ecryptfs .secret/ .secret/ -o \ key=openssl:keyfile=mykey.pem:passfile=passfile.txt,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbosity=0 Actual results: mount.ecryptfs fails with error and filesystem is not mounted. -mount.ecryptfs output: Attempting to mount with the following options: Error mounting eCryptfs; rc = [-22]; strerr = [Invalid argument]. Check your system logs; visit <http://ecryptfs.sourceforge.net/ecryptfs-faq.html>. -dmesg says: ecryptfs_parse_options: eCryptfs: unrecognized option 'verbosity=0' ecryptfs_parse_options: You must supply at least one valid auth tok signature as a mount parameter; see the eCryptfs README Error parsing options; rc = [-22] Expected results: Filesystem is mounted without errors. Additional info: If I use 'passwd=secret' instead of 'passfile=passfile.txt' filesystem is mounted without errors.
Note that only keyfiles generated by the eCryptfs key module via the ecryptfs-manager utility are currently supported. The correct OpenSSL key module parameter for specifying a file containing a keyfile passphrase is "passwd_file". If this is documented incorrectly in the man pages, this needs to be corrected. The passwd_file option for the openssl key module is not implemented in release 38. It is implemented in release 40, which is currently in Fedora devel. Mike
Reopening just to let Karsten decide if he wants to pull this into RHEL5, since that's what the bug was opened against... Thanks, -Eric
Latest packages for RHEL-5.2 already are based on ecryptfs-utils-40 so they already contain the fix. Just flagged the bug appropriately and will close it as soon as we ship the errata. Read ya, Phil
Confirming it works in 40 and is failing in 38. -- NEW: ---- dhcp-lab-198 mounting # rpmquery ecryptfs-utils ecryptfs-utils-40-1.el5 dhcp-lab-198 mounting # mount.ecryptfs .secret/ .secret/ -o key=openssl:keyfile=mykey.pem:passwd_file=passfile.txt,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbosity=0 Attempting to mount with the following options: ecryptfs_key_bytes=16 ecryptfs_cipher=aes ecryptfs_sig=b2230a51354c73d2 Mounted eCryptfs OLD: ---- dhcp-lab-198 mounting # rpmquery ecryptfs-utils ecryptfs-utils-38-1.el5 dhcp-lab-198 mounting # umount .secret/ dhcp-lab-198 mounting # umount .secret/ umount: .secret/: not mounted dhcp-lab-198 mounting # mount.ecryptfs .secret/ .secret/ -o key=openssl:keyfile=mykey.pem:passwd_file=passfile.txt,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbosity=0 Attempting to mount with the following options: ecryptfs_key_bytes=16 ecryptfs_cipher=aes Error mounting eCryptfs; rc = [-22]; strerr = [Invalid argument]. Check your system logs; visit <http://ecryptfs.sourceforge.net/ecryptfs-faq.html>. dhcp-lab-198 mounting # mount | grep secret -- I believe it's worth fixing it.
dhcp-lab-198 openssl-keyfile # mkdir secret dhcp-lab-198 openssl-keyfile # ecryptfs-manager eCryptfs key management menu ------------------------------- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 3 Select key type to use for newly created files: 1) openssl Selection: 1 SSL key file path [/root/.ecryptfs/pki/openssl/key.pem]: mykey.pem Passphrase: Returning to main menu eCryptfs key management menu ------------------------------- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 dhcp-lab-198 openssl-keyfile # ls -l mykey.pem -rw-r--r-- 1 root root 986 Feb 26 08:32 mykey.pem dhcp-lab-198 openssl-keyfile # mount.ecryptfs secret/ secret/ -o key=openssl:keyfile=mykey.pem:passwd_file=passfile.txt,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,verbosity=0 Attempting to mount with the following options: ecryptfs_key_bytes=16 ecryptfs_cipher=aes ecryptfs_sig=cc8a94c1c8630ad3 Mounted eCryptfs dhcp-lab-198 openssl-keyfile # echo "secrettext" > secret/stf.txt -bash: secret/stf.txt: Transport endpoint is not connected dhcp-lab-198 openssl-keyfile # ls -l secret/ total 4 -rw-r--r-- 1 root root 0 Feb 26 08:34 stf.txt dhcp-lab-198 openssl-keyfile # echo "secrettext" > secret/stf.txt -bash: secret/stf.txt: Input/output error -- dhcp-lab-198 newman # Feb 26 08:49:23 dhcp-lab-198 kernel: ecryptfs_send_message: User [0] does not have a daemon registered Feb 26 08:49:23 dhcp-lab-198 kernel: pki_encrypt_session_key: Error sending netlink message Feb 26 08:49:23 dhcp-lab-198 kernel: write_tag_1_packet: Failed to encrypt session key via a pki<4>ecryptfs_generate_key_packet_set: Error writing tag 1 packet Feb 26 08:49:23 dhcp-lab-198 kernel: ecryptfs_write_headers_virt: Error generating key packet set; rc = [-107] Feb 26 08:49:23 dhcp-lab-198 kernel: ecryptfs_write_metadata: Error whilst writing headers Feb 26 08:49:23 dhcp-lab-198 kernel: Error writing headers; rc = [-107] Feb 26 08:49:23 dhcp-lab-198 kernel: Error attempting to read the [user.ecryptfs] xattr from the lower file; return value = [4294967235] Feb 26 08:49:23 dhcp-lab-198 kernel: Attempt to read file that is not in a valid eCryptfs format, and plaintext passthrough mode is not enabled; returning -EIO --
> ecryptfs_send_message: User [0] does not have a daemon registered When using a non-passphrase key module, the user accessing the eCryptfs mount point needs to have the ecryptfsd daemon running. Mike
Thanks Mike, got it. Works OK then.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2008-0430.html