Arch Linux recently changed their default toolchain flags to a more secure combination [1]. Most likely because of this, executables are now recognized as shared objects, e.g., output from "file": a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=941b4da3c6b4b43727371ae88aa0b54f6d493487, not stripped Thunar thinks the same, and after double-clicking an executable it asks which program to use to open a shared object. Instead, Thunar should execute these types of files just like regular executables. Note: some ELF shared libraries actually are also runnable as executables, for example, "/lib/libc.so.6" on a typical Linux system. [1] https://lists.archlinux.org/pipermail/arch-dev-public/2017-June/028903.html
Created attachment 7241 gfile-test.c The problem is how actually determine whether shared lib is executable. `file --mime-type` applied against these binaries says 'application/x-sharedlib', g_file_query_info contains the same mime type. But in glib opinion this type is not executable (g_content_type_can_be_executable for 'application/x-sharedlib' will return FALSE). I'm attaching a simple program which demonstrates this behavior. There should be another way to check whether file is executable instead of relying on mime type.
I am not sure if there is any reasonable way, except treating all files with executable bit as executables. Checking a test executable and a regular shared library with "readelf -h" shows that they both have type "DYN (Shared object file)" and both have an entry point. If Thunar uses g_content_type_can_be_executable(), then perhaps I should forward this bug report to Glib developers?
glib developers can't solve this since not all 'application/x-sharedlib' can be actually executed. The problem is more fundamental: even `file` utility returns this mime type. The difference only in that executable shared libs have INTERP header (so `file` utility prints 'interpreter /lib64/ld-linux-x86-64.so.2'). So no matter where it will be changed: in glib or in thunar directly. Replying on mime type now is bad idea (but thunar does it).
Note that not all executables will have an interpreter section. For example, statically linked executables do not have it.
shared-mime-info bug: https://bugs.freedesktop.org/show_bug.cgi?id=97226
things must have moved on with the "file" app as I see $ file --mime-type shader-mask shader-mask: application/x-pie-executable rather than the output above
*** Bug 13750 has been marked as a duplicate of this bug. ***
https://bugzilla.xfce.org/show_bug.cgi?id=13750#c0 provides some more details around ASLR, which seems to be the cause of the problem.
I updated the title for better clarity.
-- 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/168. 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