Description: As of now opening setting up a link pointing to a file with 'x' permission (execute -rwx------ for example) on MacOS or Linux (using CMD+K or HYPERLINK function) result in a generic error that say: "PATH is not an absolute URL that can be passed to an external application to open it.". Apart from it to be misleading because the path DOES exist, it is also counterproductive in the scenario we have the link pointing to an SMB (CIFS) sharing, here is not always easy to set the right permissions so we usually have the execute bit always set, even on PDF files for example, resulting in the impossibility to open that file. A much better handle of the problem would be to open a dialog with a big alert warning saying that the file is executable and we should be careful with it, and so give user the ability to choose what to do. Steps to Reproduce: 1. Create a link with CMD+X (or CTRL+K) or HYPERLINK function 2. Point it to a PDF with the executable bit set (with chmod 700 for example) 3. Try to open it Actual Results: It gives an error as expected (even if the phrasing is misleading). But this is not a good implementation and lead to problems on SMB shares. Expected Results: Give user the choice to open or not the file with a big warning! Because many times this can be a false positive Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.0.4.2 Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Mac OS X 10.16; UI render: GL; VCL: osx Locale: it-IT (it_IT.UTF-8); Interfaccia utente: it-IT Calc: threaded
Useful links: https://www.libreoffice.org/about-us/security/advisories/cve-2019-9847/ https://ask.libreoffice.org/en/question/255719/hyperlink-with-cell-references-doesnt-work-reliably/
Since you haven't indicated you've tested this bug on a previous version, earliest version stays at 7.0.4
Tested on this versions: WORKING Version: 6.2.2.2 Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx; Locale: it-IT (it_IT.UTF-8); UI-Language: en-US Calc: threaded WORKING Version: 6.2.3.1 Build ID: 9ba025bafb03b962c34687cf87806cc03a3a7436 CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx; Locale: it-IT (it_IT.UTF-8); UI-Language: en-US Calc: threaded NOT WORKING Version: 6.2.3.2 Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx; Locale: it-IT (it_IT.UTF-8); UI-Language: en-US Calc: threaded
Further informations: See https://github.com/LibreOffice/core/blob/10f8764ff9c3945e3e51c7d483dc7a07bdea29f9/shell/source/unix/exec/shellexec.cxx#L135 the file in question. Marked line is where libreoffice checks for the executable bit, we need to throw a different error and report it to openuriexternally.cxx, create a dialog like "Are you sure to open this file even if it is an executable?" then if answered yes return back to shellexec and force it to open. See also https://github.com/LibreOffice/core/commit/d59ec4cd1660410fa1b18c50d2d83b1417a82ddc for the commit that changed the behavior And https://github.com/LibreOffice/core/blob/master/sfx2/source/appl/openuriexternally.cxx for the UI calling it
Created attachment 170757 [details] Patch for openuriexternally.cxx
Created attachment 170758 [details] Patch for shellexec.cxx
I want to help so here are the patches, you will find TODOs on each line i changed. I'm not expert in C nor have a compiler so maybe there is something wrong but it should work. Check it out
I can confirm this Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 10; OS: Mac OS X 12.2; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Resolved in bug 128969 for version 7.3?
(In reply to Mike Kaganski from comment #9) > Resolved in bug 128969 for version 7.3? Sadly not. The fix for bug 128969 bring up indeed the warning message but seems like that after confirming you want to open it anyway it fails again. As a side note this still work like before: on local filesystem everything works fine (it opens a PDF file) but the same file on a remote filesystem does not open because of the file permission set (and no, spaces or special chars are not the issue, see comment #1 of this issue). Will take a look at the source later to try to help find where the issue is. Tried with the daily build (07/03/22) of LO 7.3 for MacOS.
(In reply to cv from comment #0) > Description: > As of now opening setting up a link pointing to a file with 'x' permission > (execute -rwx------ for example) on MacOS or Linux (using CMD+K or HYPERLINK I think this is specific to macOS, and doesn't occur on Linux, right? > function) result in a generic error that say: "PATH is not an absolute URL > that can be passed to an external application to open it.". > Apart from it to be misleading because the path DOES exist, it is also > counterproductive in the scenario we have the link pointing to an SMB (CIFS) > sharing, here is not always easy to set the right permissions so we usually > have the execute bit always set, even on PDF files for example, resulting in > the impossibility to open that file.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0bbbde84b091c7969378ef9a5bbadd9706e57c5e tdf#140886: Make "Do you really want to open it?" more reliable It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.