Bug 41692

Summary: Obscure improper EACCES with ecryptfs_xattr_metadata
Product: File System Reporter: Christopher Head (bugs)
Component: ecryptfsAssignee: fs_ecryptfs
Status: NEW ---    
Severity: normal CC: code, xerofoify
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.39 Subsystem:
Regression: No Bisected commit-id:

Description Christopher Head 2011-08-25 03:24:20 UTC
Assume that directory "/mnt" is the plaintext view of an ecryptfs volume.

Assume that file "/mnt/foo" does not exist.

Assume that the volume is mounted with ecryptfs_xattr_metadata.

Assume that the underlying volume be ext4, mounted with user_xattr.

The following system call fails with EACCES:

open("/mnt/foo", O_RDWR | O_CREAT | O_EXCL, 0444)

According to the man page:

       O_CREAT
              If  the  file  does not exist it will be created.  The owner (user ID) of the file is set to the effective user ID of
              the process.  The group ownership (group ID) is set either to the effective group ID of the process or to  the  group
              ID  of  the  parent directory (depending on file system type and mount options, and the mode of the parent directory,
              see the mount options bsdgroups and sysvgroups described in mount(8)).

              mode specifies the permissions to use in case a new file is created.  This argument must be supplied when O_CREAT  is
              specified in flags; if O_CREAT is not specified, then mode is ignored.  The effective permissions are modified by the
              process's umask in the usual way: The permissions of the created file are (mode & ~umask).  Note that this mode  only
              applies to future accesses of the newly created file; the open() call that creates a read-only file may well return a
              read/write file descriptor.

Hence the failure is non-compliant: the open should succeed and return the only writable file descriptor that can ever be created to the file without chmodding it.

The error occurs when ecryptfs tries to write the metadata xattr to the underlying file, which is read-only, since the xattr work doesn't happen through a file descriptor.

I could imagine there might be a race in there as well, where a file created as 0644 but chmodded to 0444 by another thread might also fail to be created for the same reason.
Comment 1 xerofoify 2014-06-25 16:10:45 UTC
This bug is outdated. Please test against a newer kernel.
Thanks Nick
Comment 2 Christopher Head 2014-06-28 05:26:20 UTC
I tried to reproduce this on 3.12.21. Instead, when I do “echo hello > foo” in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:

[  942.126335] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  942.126342] IP: [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
[  942.126353] PGD d7840067 PUD b2c3c067 PMD 0 
[  942.126359] Oops: 0002 [#1] SMP 
[  942.126363] Modules linked in: nvidia(PO)
[  942.126372] CPU: 3 PID: 3566 Comm: bash Tainted: P           O 3.12.21-gentoo-r1 #2
[  942.126375] Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010
[  942.126379] task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000
[  942.126381] RIP: 0010:[<ffffffff8110eb39>]  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
[  942.126389] RSP: 0018:ffff8800bad71c10  EFLAGS: 00010246
[  942.126392] RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000
[  942.126394] RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000
[  942.126397] RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000
[  942.126400] R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000
[  942.126403] R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40
[  942.126407] FS:  00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000
[  942.126410] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  942.126413] CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0
[  942.126415] Stack:
[  942.126416]  ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a
[  942.126422]  ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c
[  942.126428]  00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220
[  942.126434] Call Trace:
[  942.126442]  [<ffffffff811826e8>] ? ecryptfs_setxattr+0x40/0x52
[  942.126449]  [<ffffffff81185fd5>] ? ecryptfs_write_metadata+0x1b3/0x223
[  942.126456]  [<ffffffff81082c2c>] ? should_resched+0x5/0x23
[  942.126461]  [<ffffffff8118322b>] ? ecryptfs_initialize_file+0xaf/0xd4
[  942.126466]  [<ffffffff81183344>] ? ecryptfs_create+0xf4/0x142
[  942.126472]  [<ffffffff810f8c0d>] ? vfs_create+0x48/0x71
[  942.126478]  [<ffffffff810f9c86>] ? do_last.isra.68+0x559/0x952
[  942.126483]  [<ffffffff810f7ce7>] ? link_path_walk+0xbd/0x458
[  942.126488]  [<ffffffff810fa2a3>] ? path_openat+0x224/0x472
[  942.126493]  [<ffffffff810fa7bd>] ? do_filp_open+0x2b/0x6f
[  942.126500]  [<ffffffff81103606>] ? __alloc_fd+0xd6/0xe7
[  942.126507]  [<ffffffff810ee6ab>] ? do_sys_open+0x65/0xe9
[  942.126514]  [<ffffffff8157d022>] ? system_call_fastpath+0x16/0x1b
[  942.126516] Code: 89 f2 48 89 fe bf 9c ff ff ff e9 52 ff ff ff 0f 1f 00 48 8b 56 48 48 8b 86 88 00 00 00 48 89 57 48 48 89 87 88 00 00 00 c3 8b 06 <66> 89 07 8b 46 04 89 47 04 8b 46 08 89 47 08 8b 46 44 89 47 44 
[  942.126569] RIP  [<ffffffff8110eb39>] fsstack_copy_attr_all+0x2/0x61
[  942.126575]  RSP <ffff8800bad71c10>
[  942.126577] CR2: 0000000000000000
[  942.126580] ---[ end trace df9dba5f1ddb8565 ]---
Comment 3 Tyler Hicks 2014-07-03 22:14:16 UTC
(In reply to Christopher Head from comment #2)
> I tried to reproduce this on 3.12.21. Instead, when I do “echo hello > foo”
> in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:
> 
> [  942.126335] BUG: unable to handle kernel NULL pointer dereference at     
> (null)

Hi Christopher - Could you please open a new bug report for this issue? I'll get it fixed next week. Thanks!