[Bugme-new] [Bug 41692] New: Obscure improper EACCES with ecryptfs_xattr_metadata
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Wed Aug 24 20:24:22 PDT 2011
https://bugzilla.kernel.org/show_bug.cgi?id=41692
Summary: Obscure improper EACCES with ecryptfs_xattr_metadata
Product: File System
Version: 2.5
Kernel Version: 2.6.39
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ecryptfs
AssignedTo: fs_ecryptfs at kernel-bugs.osdl.org
ReportedBy: headch at gmail.com
Regression: No
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.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Bugme-new
mailing list