! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Thunar displays false-negative read permission emblems on file systems using ...
Status:
RESOLVED: MOVED

Comments

Description Martijn Dekker 2015-03-05 02:21:26 CET
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.
Comment 1 Harald Judt editbugs 2015-04-17 17:32:10 CEST
This does bypass the cache in thunar, so not a good idea to apply in its current state.
Comment 2 Git Bot editbugs 2020-05-26 23:21:13 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/100.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #11645

Reported by:
Martijn Dekker
Reported on: 2015-03-05
Last modified on: 2020-05-26

People

Assignee:
Xfce Bug Triage
CC List:
2 users

Version

Version:
unspecified

Attachments

Additional information