Thunar displays false-negative read permission emblems on file systems using ACLs; patch attached

Submitted by Martijn Dekker

Assigned to Xfce Bug Triage

Link to original bug (#11645)

Description

Created attachment 6033 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.

Attachment 6033, "Patch: Filesystem-independent read permission check for thunar-file.c":
filesys-indep-permcheck.diff