Bug 467234 - openssl module reports invalid packet format error on file creation in ecryptfs filesystem
Summary: openssl module reports invalid packet format error on file creation in ecrypt...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ecryptfs-utils
Version: 5.3
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Karsten Hopp
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-16 14:31 UTC by Jan Tluka
Modified: 2009-01-20 21:59 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:59:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
proposed fix (516 bytes, patch)
2008-10-21 22:06 UTC, Eric Sandeen
no flags Details | Diff
xattr error reproducer (1.29 KB, application/x-sh)
2008-10-22 15:37 UTC, Jan Tluka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0203 0 normal SHIPPED_LIVE ecryptfs-utils bug fix and enhancement update 2009-01-20 16:06:10 UTC

Description Jan Tluka 2008-10-16 14:31:04 UTC
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:

Comment 1 RHEL Program Management 2008-10-21 15:21:02 UTC
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.

Comment 2 Eric Sandeen 2008-10-21 15:39:25 UTC
Jan, it's marked regression... so this worked in the 5.2 code drop?  (I'll go test ...)

Comment 3 Jarod Wilson 2008-10-21 15:43:14 UTC
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...

Comment 4 Jarod Wilson 2008-10-21 15:50:17 UTC
Whoops, sorry, missed the 'pgrep ecryptfsd' part.

Comment 5 Jan Tluka 2008-10-21 17:09:30 UTC
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.

Comment 6 Jan Tluka 2008-10-21 17:14:41 UTC
Sorry. Previous comment 5 should be a response to Eric's comment 2. However explicitly shows regression.

Comment 7 Eric Sandeen 2008-10-21 17:19:05 UTC
yes, I tested it and also found it to work in 5.2, thanks.

-Eric

Comment 8 Eric Sandeen 2008-10-21 22:06:22 UTC
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.

Comment 10 Jan Tluka 2008-10-22 10:22:22 UTC
Hi Eric, with rebuilded source rpm provided by you in comment 9 it works without errors.

Comment 11 Jan Tluka 2008-10-22 15:00:54 UTC
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.

Comment 12 Eric Sandeen 2008-10-22 15:05:15 UTC
Jan, which xattr tests?  I recently (last couple of days...) found a a serious kernel bug when using xattrs to store the crypto headers...

Comment 13 Jan Tluka 2008-10-22 15:21:54 UTC
By 'xattr' I mean xattr part of /kernel/filesystems/ecryptfs-extended test from RHTS.

Comment 14 Jan Tluka 2008-10-22 15:36:20 UTC
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]

Comment 15 Jan Tluka 2008-10-22 15:37:58 UTC
Created attachment 321168 [details]
xattr error reproducer

This is the script for xattr error reproduction.

Comment 16 Eric Sandeen 2008-10-22 16:54:39 UTC
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....

Comment 20 Eric Sandeen 2008-10-28 20:05:22 UTC
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)

Comment 22 Karsten Hopp 2008-10-29 13:56:28 UTC
I've dropped the release note request as 5.3 will have a package with Eric's fix.

Comment 23 Karsten Hopp 2008-10-29 13:56:28 UTC
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)

Comment 30 errata-xmlrpc 2009-01-20 21:59:50 UTC
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


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