Bug 41692
| Summary: | Obscure improper EACCES with ecryptfs_xattr_metadata | ||
|---|---|---|---|
| Product: | File System | Reporter: | Christopher Head (bugs) |
| Component: | ecryptfs | Assignee: | 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: | |
This bug is outdated. Please test against a newer kernel. Thanks Nick 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 ]--- (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! |
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.