[Xfce-bugs] [Bug 11645] New: Thunar displays false-negative read permission emblems on file systems using ACLs; patch attached

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=11645

            Bug ID: 11645
           Summary: Thunar displays false-negative read permission emblems
                    on file systems using ACLs; patch attached
    Classification: Xfce
           Product: Thunar
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: Medium
         Component: general
          Assignee: xfce-bugs at xfce.org
          Reporter: mcdutchie at hotmail.com
        QA Contact: nick at xfce.org
                CC: benny at xfce.org

Created attachment 6033
  --> https://bugzilla.xfce.org/attachment.cgi?id=6033&action=edit
Patch: Filesystem-independent read permission check for thunar-file.c

Bug:

On file systems that use access controls other than Unix permission bits,
Thunar shows false-negative read permission emblems on icons (the big red X).

For instance, at $WORK we run a Linux ext4 file system that makes extensive use
of POSIX ACLs, because classic Unix permission bits just won't do for our
needs. Users running Thunar were continually seeing big X emblems on files and
folders to which they did in fact have read access through an ACL. This
rendered those emblems both meaningless and annoying.

Proposed fix:

The attached patch fixed this for us so accurate big-red-X emblems are shown.
It replaces the read permission checking logic in thunar-file.c with a much
simpler approach: try to fopen() the file for reading to see if we're allowed
to read it. fopen() causes the operating system to perform a permission check
according to whatever filesystem is in use. If there is no read access
permission, the call fails with a NULL stream pointer, and the read access
checking function returns false. If the call succeeds, the stream is
immediately closed again, and the function returns true.

Performance considerations:

I have not noticed any performance penalty. No actual read operation is done by
only calling fopen() and fclose(). We're only accessing a directory that we've
just been accessing anyway, so any file system data needed would have already
been cached in RAM by the time we get to this check.

File system integrity considerations:

File access timestamps are a potential concern with this method. According to
my testing, file access timestamps on ext4 are not changed by calling
fopen(path,"r") immediately followed by fclose(). This makes sense, as no
actual read operation is done, so the file itself wouldn't be accessed, only
its directory entry. Browsing special file systems (/dev, /proc, /sys) with my
patched Thunar has also been working as expected. Further testing is needed to
check if this holds for other file systems and operating systems.

Portability considerations:

This method offloads the actual permission check onto the operating system, and
should therefore be filesystem-agnostic and OS-agnostic. This would increase
the portability of Thunar.

The use of fopen() for reading on any kind of file, even directories, is
consistent with the POSIX spec. See:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html (the
EISDIR error is only returned if the named file is a directory *and* mode
requires write access).

Security considerations:

I can think of no possible security implications associated with executing
fopen(path,"r") on a known-to-be-present file only to close the stream again,
but that doesn't mean there aren't any.

-- 
You are receiving this mail because:
You are the assignee for the bug.