[Bugme-new] [Bug 41692] New: Obscure improper EACCES with ecryptfs_xattr_metadata

[bugzilla-daemon at bugzilla.kernel.org]

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.