Bug 448797 - Files created in eCryptfs overlay atop NFS disappear
Files created in eCryptfs overlay atop NFS disappear
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Eric Sandeen
:
Depends On:
Blocks: 533192
  Show dependency treegraph
 
Reported: 2008-05-28 16:33 EDT by Jarod Wilson
Modified: 2012-01-09 17:03 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-09 17:03:16 EST
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 2008-05-28 16:33:01 EDT
Description of problem:
File created in an ecryptfs overlay atop an nfs share disappear.

Two machines involved: "server" is an nfs server, sharing out "/data", "client"
is a workstation mounting /data from server.

The client has /data mounted from the server, and now creates a directory
/data/encrypted, and proceeds to mount an ecryptfs overlay atop /data/encrypted
(using selinux xattr work-around in bug 448787):

[client]# mount -t ecryptfs /data/encrypted /data/encrypted -o
context=system_u:object_r:user_home_t:s0
Select key type to use for newly created files: 
 1) openssl
 2) passphrase
Selection: 2
Passphrase: 
Verify 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]: 
Select key bytes: 
 1) 16
 2) 32
 3) 24
Selection [16]: 2
Enable plaintext passthrough (y/n): n
Attempting to mount with the following options:
  ecryptfs_key_bytes=32
  ecryptfs_cipher=aes
  ecryptfs_sig=92868a6a72b0202e
Mounted eCryptfs

[client]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5              41G  1.6G   37G   5% /
/dev/sda1             190M   29M  152M  16% /boot
tmpfs                 437M     0  437M   0% /dev/shm
xenon:/data           101G   41G   55G  43% /data
/data/encrypted       101G   41G   55G  43% /data/encrypted

[client]# echo "wasabi" > /data/encrypted/foo

[client]# ll
total 12
-rw-r--r-- 1 root root 7 May 28 15:57 foo

----WAIT A MINUTE OR TWO----

[client]# ll
total 0

???

At this point, an ll on the server side works just fine, shows the encrypted
file and everything. Oddly enough, trying to cat the file client-side actually
still works.

Unmounting the ecryptfs overlay reveals the file to ls again. Re-mounting the
ecryptfs overlay results in the file being there for one ls iteration, then
disappearing again.


Version-Release number of selected component (if applicable):
kernel-2.6.18-92.el5
ecryptfs-utils-41-1.el5
Comment 1 Jarod Wilson 2008-05-28 16:38:16 EDT
Whoops, this should be against kernel, not ecryptfs-utils.
Comment 2 Eric Sandeen 2008-06-03 13:30:23 EDT
Mike has an nfs-related patch that I have rolled into my 2.6.26 ecryptfs
backport for 5.3; testing it now.   So far this simple test seems ok.
Comment 3 Jarod Wilson 2008-06-03 14:45:15 EDT
Yep, looking much better here now too.
Comment 4 Eric Sandeen 2008-06-03 17:03:46 EDT
copying a kernel tree onto ecryptfs-over-nfs-client-mount worked, but "make
clean" exploded.  We still have nfs problems, though apparently not this
specific one.
Comment 5 Jarod Wilson 2008-06-04 17:46:32 EDT
I've successfully copied a kernel source tree onto an ecryptfs-on-nfs mount w/o
a problem so far, now doing a kernel build. First thing that jumps out is
constant spew about files having modification times some random amount of time
between 2.5 and 11 seconds in the future. Will give a make clean a try once the
kernel build is done. For the record, the nfs server in this case is another
rhel5 box.
Comment 6 Jarod Wilson 2008-06-06 11:31:45 EDT
The 'make clean' exploded here too, filed bug 450144 for that problem. Still
need to poke at the modification time thing, may just have been a generic nfs
thing, since the clocks on the server and client weren't in sync.
Comment 7 Jarod Wilson 2008-06-13 15:47:14 EDT
Yep, chalk up the modification time thing to the server and client having clocks
a ways out of sync. All's well on this front if they're both keeping time correctly.
Comment 8 Eric Sandeen 2008-08-27 13:20:23 EDT
Moving this to 5.4; still no fix upstream and I've not been able to resolve it.  We'll need to release-note ecryptfs in 5.3 with caveats about NFS, I think?
Comment 9 RHEL Product and Program Management 2008-08-27 13:33:28 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Eric Sandeen 2008-08-27 15:19:07 EDT
Note, RHEL5.3 will have a patch to disallow mounts on NFS due to the severity
of the problems.
Comment 11 RHEL Product and Program Management 2009-02-16 10:44:17 EST
Updating PM score.
Comment 12 Eric Sandeen 2009-03-12 12:47:23 EDT
Moving this off to 5.5.  AFAIK it's still broken upstream, and we have patches to prevent nfs mounts, so customers won't see this (with the restricted ability to use nfs, that is)
Comment 13 Emmanuel Galanos 2009-08-30 19:17:55 EDT
Still broken in Fedora 11 (2.6.29.6-217.2.16.fc11.x86_64)

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