Hmm:

[root@localhost ~]# mount -t ecryptfs secret secret
Select key type to use for newly created files:
 1) passphrase
 2) openssl
Selection: 1
Passphrase: 
Verify Passphrase: 
Cipher
1) AES-128
2) AES-192
3) AES-256
4) Triple-DES
5) Twofish
6) CAST5
7) CAST6
8) Blowfish
Selection [AES-128]: 
Enable plaintext passthrough (y/n): y
Attempting to mount with the following options:
  ecryptfs_passthrough
  ecryptfs_cipher=aes
  ecryptfs_key_bytes=16
  ecryptfs_sig=253ca7e88811d184
Mounted eCryptfs
[root@localhost ~]# cd secret
[root@localhost secret]# echo foo > junk
[root@localhost secret]# cat junk
foo

that was on 2.6.23.1-30.fc8 #1 SMP Mon Oct 22 18:46:28 EDT 2007 i686 i686 i386
GNU/Linux and ecryptfs-utils-18-1.fc8
....

-Eric

Hi Eric,

Your session in Comment #1 was on a 32 bit x86, right? The session I cut and
pasted was from an x86_64. Perhaps then it is 64 bit specific.

This is a clue as to what went wrong:

---
Error opening lower file for lower_dentry [0xffff81004e995270],
lower_mnt [0xffff810037fece00], and flags [0x8003]
ecryptfs_open: Error opening lower file
---

The version of eCryptfs in 2.6.23 probably doesn't handle failures to open files
in the lower filesystem gracefully. The failure to open the file in the lower
filesystem may have been due to DAC permissions or a MAC (SELinux) denial.
Jonathan: you can verify this by making sure that you have write permission to
your lower directory; also, see if it bombs out when setenforce=0.

(Note that the mechanism for opening the lower file is completely different in
2.6.24-rc, so this bug may not even manifest in the latest release).

Mike

I did have selinux off, but things still worked ok after re-enabling it. 
Jonathan, I need to get an x86_64 box set up with F8, then can test there.  Did
you have any other selinux-related messages in your failure case, or any other
clues to why the file open failed?

FWIW:
[root@localhost ~]# ls -Zd secret
drwxr-xr-x  root root root:object_r:sysadm_home_t:s0   secret

is the security context for the secret/ dir I tested with.

Creating a new dir when selinux was on, I got:

[root@localhost ~]# ls -Zd secret3
drwxr-xr-x  root root root:object_r:sysadm_home_dir_t:s0 secret3

but that worked fine too.

For sanity, I reproduced this just now at the first attempt, and verified the
SElinux permissions:

[root@renton ~]# ls -Zd secret/
drwxr-xr-x  root root system_u:object_r:sysadm_home_dir_t:s0 secret/
[root@renton ~]# mount -t ecryptfs /root/secret /root/secret
Select key type to use for newly created files:
 1) openssl
 2) passphrase
Selection: 2
Passphrase: 
Verify Passphrase: 
Cipher
1) Triple-DES
2) AES-128
3) AES-192
4) AES-256
5) CAST6
6) Blowfish
7) CAST5
8) Twofish
Selection [AES-128]: 
Enable plaintext passthrough (y/n): 
Attempting to mount with the following options:
  ecryptfs_cipher=aes
  ecryptfs_key_bytes=16
  ecryptfs_sig=27aa52467bde3b5d
Mounted eCryptfs
[root@renton ~]# cd secret
[root@renton secret]# touch junk
[root@renton secret]# echo foo > junk
[jgu@renton ~]$ 
Message from syslogd@renton at Nov 10 23:26:10 ...
 kernel: ------------[ cut here ]------------

Message from syslogd@renton at Nov 10 23:26:10 ...
 kernel: invalid opcode: 0000 [1] SMP 

Note how my root shell is killed. Everything related to this in dmesg:

SELinux: initialized (dev ecryptfs, type ecryptfs), uses xattr
Error opening lower file for lower_dentry [0xffff81004de03340], lower_mnt
[0xffff81007e58b500], and flags [0x8003]
ecryptfs_open: Error opening lower file
------------[ cut here ]------------
kernel BUG at include/linux/dcache.h:322!
invalid opcode: 0000 [1] SMP 
CPU 1 
Modules linked in: cbc aes ecryptfs i915 drm nf_conntrack_ipv4 ipt_REJECT
iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack nfnetlink
ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand
acpi_cpufreq dm_mirror dm_multipath dm_mod snd_hda_intel snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq arc4 snd_seq_device ecb snd_pcm_oss
blkcipher b44 snd_mixer_oss snd_pcm firewire_ohci firewire_core snd_timer ssb
snd_page_alloc snd_hwdep sdhci snd crc_itu_t mii iTCO_wdt soundcore
iTCO_vendor_support mmc_core iwl3945 battery i2c_i801 ac video output button
i2c_core mac80211 joydev cfg80211 sg sr_mod cdrom ata_generic ata_piix libata
sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
Pid: 3722, comm: bash Not tainted 2.6.23.1-42.fc8 #1
RIP: 0010:[<ffffffff8836c1a4>]  [<ffffffff8836c1a4>]
:ecryptfs:ecryptfs_open_lower_file+0x1d/0x83
RSP: 0018:ffff81004d7d3dd8  EFLAGS: 00010246
RAX: ffff81007d6b3b88 RBX: ffff81004de03340 RCX: 0000000000000003
RDX: ffff81007e58b500 RSI: ffff81004de03340 RDI: ffff81004d7d3e28
RBP: ffff81007e58b500 R08: ffff81004d7d3d88 R09: 0000000000000000
R10: ffff81004d7d3b78 R11: 0000000000100005 R12: ffff81004d7a85b8
R13: ffff81004d7d3e28 R14: ffff81007e58b500 R15: ffff81004de03750
FS:  00002aaaaaac4f50(0000) GS:ffff810037cd8300(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000008d7508 CR3: 000000004cd1d000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 3722, threadinfo ffff81004d7d2000, task ffff81004c566810)
Stack:  ffff81005c656000 ffff81004d7a8380 ffff81005c656000 ffff81004d7a85b8
 ffff81004d7a86d8 ffffffff8836c545 ffff81004d7a8380 ffff81007e503c08
 ffff81004de03340 0000000000000000 0000000000000000 ffff81005c656000
Call Trace:
 [<ffffffff8836c545>] :ecryptfs:ecryptfs_open+0x12a/0x28b
 [<ffffffff8836c41b>] :ecryptfs:ecryptfs_open+0x0/0x28b
 [<ffffffff8109a0e8>] __dentry_open+0xf4/0x1c5
 [<ffffffff8109a26d>] do_filp_open+0x2a/0x38
 [<ffffffff81099f40>] get_unused_fd_flags+0x72/0x11f
 [<ffffffff8109a2c1>] do_sys_open+0x46/0xc3
 [<ffffffff8100bd45>] tracesys+0xd5/0xda


Code: 0f 0b eb fe f0 ff 06 48 85 ed 74 07 f0 ff 85 c0 00 00 00 41 
RIP  [<ffffffff8836c1a4>] :ecryptfs:ecryptfs_open_lower_file+0x1d/0x83
 RSP <ffff81004d7d3dd8>

i.e no SElinux denial messages.

I then tried the same thing with selinux turned off:

[jgu@renton ~]$ su -
Password: 
[root@renton ~]# cd /root
[root@renton ~]# /usr/sbin/setenforce 0
[root@renton ~]# mkdir secret2
[root@renton ~]# ls -Zd secret/
drwxr-xr-x  root root system_u:object_r:sysadm_home_dir_t:s0 secret/
[root@renton ~]# mount -t ecryptfs /root/secret2 /root/secret2
Select key type to use for newly created files:
 1) openssl
 2) passphrase
Selection: 2
Passphrase: 
Verify Passphrase: 
Cipher
1) Triple-DES
2) AES-128
3) AES-192
4) AES-256
5) CAST6
6) Blowfish
7) CAST5
8) Twofish
Selection [AES-128]: 
Enable plaintext passthrough (y/n): 
Attempting to mount with the following options:
  ecryptfs_cipher=aes
  ecryptfs_key_bytes=16
  ecryptfs_sig=27aa52467bde3b5d
Mounted eCryptfs
[root@renton ~]# cd service2
-bash: cd: service2: No such file or directory
[root@renton ~]# cd secret2
[root@renton secret2]# touch junk
[root@renton secret2]# echo foo > junk
[root@renton secret2]# 

So, it very much does seem to be an SElinux issue causing ecryptfs to bomb out.

For reference:
[root@renton secret2]# ls -Z junk 
-rw-r--r--  root root system_u:object_r:sysadm_home_dir_t:s0 junk
[root@renton secret2]# 

My understanding of SElinux is rather... superficial, so I can't shed much light
on this.

Oh, also, just in case it's important: 

[root@renton ~]# rpm -qa | grep selinux
selinux-policy-3.0.8-44.fc8
libselinux-2.0.37-1.fc8
libselinux-python-2.0.37-1.fc8
libselinux-2.0.37-1.fc8
selinux-policy-targeted-3.0.8-44.fc8

Still occurs with 
kernel 2.6.23.8-62 and 
libselinux-python-2.0.43-1.fc8
libselinux-2.0.43-1.fc8
libselinux-2.0.43-1.fc8
selinux-policy-targeted-3.0.8-56.fc8
selinux-policy-3.0.8-56.fc8
selinux-policy-devel-3.0.8-56.fc8

Added dwalsh, as I think this may be an SElinux problem, given that turning
SElinux off solves it.

Any chance you can try this again on 2.6.24-rcFOO?

FWIW we've done a fair amount of testing on 2.6.24-rc3-ish, on x86 and x86_64,
with and without selinus, and haven't seen this problem.

I will try over the xmas break, but won't have time this week I am afraid. 

Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Have you been able to
test against a 2.6.24-based kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

I am afraid I have been snowed under with other issues, but 2.6.24 kernels will
presumably hit F8 very soon, when I'll be able to test this once more.

(In reply to comment #12)
> I am afraid I have been snowed under with other issues, but 2.6.24 kernels will
> presumably hit F8 very soon, when I'll be able to test this once more.

Okay, thanks Jonathan. I'm setting this back to NEEDINFO so we know we're
waiting on some testing from you.

I used this in Rawhide, and it seems to work correctly without any SELinux errors.

With kernel-2.6.24.2-10.fc8 I no longer see this problem - I'll close the bug.

great, thanks for the update.