Description of problem: When creating a new file in ecryptfs filesystem there's a invalid packet format reported by ecryptfs miscdev code. Input/output error is reported by kernel. When data is written to the new file this data is lost because of that error. When data is written to an existing file the problem does not occur. Here's a console session capture of the problem: [root@intel-d3c69-01 ~]# 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]: 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 [root@intel-d3c69-01 ~]# mkdir .secret [root@intel-d3c69-01 ~]# pgrep ecryptfsd 17575 [root@intel-d3c69-01 ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /root/.secret on /root/.secret type ecryptfs (rw,ecryptfs_sig=8431864ec283561b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,) [root@intel-d3c69-01 ~]# umount .secret/ [root@intel-d3c69-01 ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) tmpfs on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) [root@intel-d3c69-01 ~]# mount -t ecryptfs .secret/ .secret/ Select key type to use for newly created files: 1) passphrase 2) openssl Selection: 2 PEM key file [/root/.ecryptfs/pki/openssl/key.pem]: Method of providing the passphrase: 1) openssl_passwd: Enter on Console 2) openssl_passwd_file: File Containing Passphrase 3) openssl_passwd_fd: File Descriptor for File Containing Passphrase Selection [openssl_passwd]: 1 Passphrase: Select cipher: 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded) 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded) 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded) Selection [aes]: 1 Select key bytes: 1) 16 2) 32 3) 24 Selection [16]: Enable plaintext passthrough (y/n) [n]: n Attempting to mount with the following options: ecryptfs_key_bytes=16 ecryptfs_cipher=aes ecryptfs_sig=8431864ec283561b WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt], it looks like you have never mounted with this key before. This could mean that you have typed your passphrase wrong. Would you like to proceed with the mount (yes/no)? yes Would you like to append sig [8431864ec283561b] to [/root/.ecryptfs/sig-cache.txt] in order to avoid this warning in the future (yes/no)? no Not adding sig to user sig cache file; continuing with mount. Mounted eCryptfs [root@intel-d3c69-01 ~]# [root@intel-d3c69-01 ~]# echo "secret" > .secret/file2 -bash: .secret/file2: Input/output error (and output on console says:) ecryptfs_miscdev_write: (1 + packet_size_length([1]) + packet_size([0]))([2]) != count([146]). Invalid packet format. pki_encrypt_session_key: Failed to receive tag 67 packet from the user space daemon Failed to encrypt session key via a key module; rc = [-5] ecryptfs_generate_key_packet_set: Error writing tag 1 packet ecryptfs_write_headers_virt: Error generating key packet set; rc = [-5] ecryptfs_write_metadata: Error whilst writing headers; rc = [-5] Error writing headers; rc = [-5] however we're able to do following: [root@intel-d3c69-01 ~]# cat .secret/file2 (the file is empty!) [root@intel-d3c69-01 ~]# echo "blah" > .secret/file2 [root@intel-d3c69-01 ~]# cat .secret/file2 blah [root@intel-d3c69-01 ~]# Version-Release number of selected component (if applicable): Installed nightly RHEL5 Server tree RHEL5.3-Server-20081015.nightly kernel-2.6.18-119.el5 ecryptfs-utils-56-4.el5 How reproducible: 100% Create openssl key, mount ecryptfs filesystem over ext3 using this key, create file in new filesystem by echoing some data into it (the file must not exist!). Steps to Reproduce: (do following steps as root, using underlying ext3 filesystem, install ecryptfs-utils before) 1. use ecryptfs-manager to create new openssl key (use default values) 2. cd ~; mkdir .secret 3. pgrep ecryptfsd; [ $? -eq 1 ] && ecryptfsd 4. mount -t ecryptfs .secret .secret 5. rm -f .secret/file 6. echo "blah" > .secret/echoed_file 7. cat .secret/echoed_file 8. grep ecryptfs /var/log/messages (search for "Invalid packet format" string) Actual results: Data we want to write into the file on file creation is lost! And in /var/log/messages I can see: ecryptfs_miscdev_write: (1 + packet_size_length([1]) + packet_size([0]))([2]) != count([146]). Invalid packet format. pki_encrypt_session_key: Failed to receive tag 67 packet from the user space daemon Failed to encrypt session key via a key module; rc = [-5] ecryptfs_generate_key_packet_set: Error writing tag 1 packet ecryptfs_write_headers_virt: Error generating key packet set; rc = [-5] ecryptfs_write_metadata: Error whilst writing headers; rc = [-5] Error writing headers; rc = [-5] Expected results: Data is written into the file on file creation. No error is reported. Additional info:
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
Jan, it's marked regression... so this worked in the 5.2 code drop? (I'll go test ...)
Hm... Using an openssl key requires the ecryptfsd userspace key helper daemon be running. Was that up and running here? The error sort of seems to indicate a problem communicating with ecryptfsd. Admittedly, openssl-based use of ecryptfs is much less tested that passphrase-based...
Whoops, sorry, missed the 'pgrep ecryptfsd' part.
Hi Jarod, I've just launched /kernel/filesystems/ecryptfs-extended test that showed following results (5.2 to 5.3 comparison): test | 5.2 | 5.3 ------------|-----------|--------- passphrase | FAILED | PASS pubkey | PASS | FAILED xattr | PASS | PASS passthrough | PASS | PASS PAM | PASS | PASS ---------------------------------- Further investigation of 'pubkey' test results in opening this bug. I used rh-tests-kernel-filesystems-ecryptfs-extended-1.1-1.
Sorry. Previous comment 5 should be a response to Eric's comment 2. However explicitly shows regression.
yes, I tested it and also found it to work in 5.2, thanks. -Eric
Created attachment 321095 [details] proposed fix The problem is with ecryptfs_send_miscdev() passing uint32_t's into ecryptfs_write_packet_length, which expects size_t's - 64 bits on x86_64. So when we filled in *packet_size_length: dest[0] = (char)size; *packet_size_length = 1; it was filling in 8 bytes, even though the memory address was to a 4 byte object; this overflowed, and happened to hit dest[0], filling it with zeros. Just changing the types seems to make things work properly.
Hi Eric, with rebuilded source rpm provided by you in comment 9 it works without errors.
Further info to comment 10: It works for openssl key but now I get some failures on xattr tests. Unfortunately they're not 100% reproducible. I'm using nightly build RHEL5.3-Server-20081020.1. As this is different from the one where original bug appeared I'm going to check it on RHEL5.3-Server-20081015.nightly, too Furhermore I will check whether xattr errors show when using in-tree ecryptfs-utils package.
Jan, which xattr tests? I recently (last couple of days...) found a a serious kernel bug when using xattrs to store the crypto headers...
By 'xattr' I mean xattr part of /kernel/filesystems/ecryptfs-extended test from RHTS.
Eric, I'm attaching another test script that should in 75% reproduce the xattr error. Test script name is simple_xattr.sh. Just specify one arg - number of mount loops (10-50 should be sufficient). It results in following messages: ecryptfs_read_lower: octets_read = [-13]; expected [4096] ecryptfs_write: Error getting page at index [0] from eCryptfs inode mapping; rc = [-22] ecryptfs_read_lower: octets_read = [-13]; expected [4096] ecryptfs_prepare_write: Error attemping to read lower page segment; rc = [-22]
Created attachment 321168 [details] xattr error reproducer This is the script for xattr error reproduction.
Jan, thanks. I think we need a new bug for that problem, it's a different root cause... and luckily, I do have a patch :) Not sure it'll make 5.3, though....
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Using openssl keys for encryption is not functional on 64-bit architectures. (until this bugfix is released, that is)
I've dropped the release note request as 5.3 will have a package with Eric's fix.
Deleted Release Notes Contents. Old Contents: Using openssl keys for encryption is not functional on 64-bit architectures. (until this bugfix is released, that is)
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 therefore 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/RHBA-2009-0203.html