Paragon makes a NTFS driver for mac. I have not used it, so whether NT’s permission scheme is fine-grained enough for this purpose is left as an exercise for the user
1 Like
Yes, the problem seems to be mostly relevant to ExFat.
- Why are you testing with a file having no extension, created via Terminal?
- In the Finder, such a file is clearly a UNIX Executable file. So why would DEVONthink do anything differently than execute it when the behavior is the same when double-clicking it in the Finder?
Note: If you disable Preferences > General > Interface > Double-click openes documents externally, it will just open a DEVONthink window instead of opening the file in Terminal and executing it.
3 Likes
I did not test nothing!
-
I just double-clicked on an item, expecting it to be displayed - sureley not it to be executed by DT!
-
I am not responsible for Apple simply declaring any executable that has not some unique file name extension to be interpreted as “Unix Executable file”.
As we all know, Apple is quite stupid, and I don’t wonder much about this wrong interpretation.
But the problem is, that ANY file on an ExFat file system has executable permission!
That simple does not not make any file an “executable”.
And even if Apple does not understand this, I am sure that DEVON Technologies understands!
About the current workaround, you mentioned - this just is NOT the solution, as you surely understand.
DT shall open *.txt in an editor, *./xls[x] in Excel and so on.
But the DEFAULT from the Files App / macOS for just executing a shell for anything else that has executable rights, is plain wrong.
As I said, DT should surely open a given file name extension with thje appropriate application!
But in any case where this is not clear, PLEASE don’t execute a shell trying to run the file!
If you have ANY sense of security, you will understand.
And it may well be, that there is NO solution possible at all within DT - I just dont’ know both macOS or DT good enough.
But right now, this is a problem for those, who use ExFat …
And this is all I wanted to inform you about.
I’ve tried to read through this entire topic, but simply don’t understand what DT has to do with some OS setting. Yes, a developer might limit some action, but wouldn’t that create a false sense of security, if the root cause is still in place?
@tja: could you at least change the topic title as there doesn’t seem to be ‘massive’ problem in DT? It’s a feature request to limit execution of files for some people that use ExFAT, but I personally doubt whether that’s a very large group to be honest.
And if you require files in multiple OS, couldn’t you simply virtualize those on macOS? AFAIK most virtualization software makes sharing files between the systems quite easy, without the need of ExFAT for example.
1 Like
Sorry, but I WORK in security topics on Unix / Linux and for me, this clearly is a security problem!
Otherwise, I would not say so.
But writing in capitals about a MASSIVE problem that only seems to effect those that use an obscure and outdated filesystem doesn’t seem appropriate to me.
Such words can create a ‘boy who cried wolf’ situation if you leave the title as is. That would be a shame as you’re seem to be very capable of detecting security issues that actually are ‘massive’, don’t you agree?
I hope the DT crew can somehow fix this for you, but still suggest you change the title and turn it into a feature request without the words ‘massive problem’.
1 Like
ExFat is by no means an “outdated” file system!
In many cases, it is the ONLY appropriate file system.
And I am not interested in a solution for ME - I can fix my own stuff perfectly well.
I am just interested in DT being informed about the problem and fixing the default for ANY and ALL users!
And by that, I mean IF this is possible at all in DT … and if not, at least to document the problem for ExFat users!
Security needs to be viewed in context
A Desktop app used by one person has very different security needs than a public web app
Assembly language code by nature is less secure than high level languages
There is always a tradeoff of security vs capability in any system. DT3 is primarily a scriptable power-user Desktop app. Its security is just fine within that context. The issues you discuss are features, not bugs.
2 Likes
It sounds to me you should report the issue you discovered to Apple. It has nothing to do with DT
2 Likes
You prefer things to be easy, it seems 
I am sure that Apple would just reply - if at all - that it is a topic for the developer of an App if and how it executes things.
Not more to say here.
I think that sums it up. I actually want to thank you; whilst I don’t fully agree with your assessment (although I’m not actually sure I’m qualified to hold that opinion), pointing out risks is the way to make people safer. Whilst there is disagreement on who needs to react, if at all, awareness of risk can contribute to reducing it. You were surprised by the behaviour you experienced (on your Mac/with DT), which suggests others might equally be surprised, and therefore at risk. Whilst there are a number of seriously literate users on this forum, not all can claim to be on that level; I would ask fellow posters not to forget that we all cater to users from across the spectrum of IT experience. To you I would suggest that the slightly excited use of capital letters in the title of your post may have got a back or two up and directed the conversation toward an immediate defensive stance.
Thanks for aiming to make DT better for us all 
Thanks, @Blanc
First occurance of understanding, I am happy.
I tried to solve the problem with a remount and changed options, but sadly (and of course) Apple does not offer the standard way to remount volumes:
tja@mini:~$ mount -t apfs -o remount,noexec /dev/disk10s1 /Volumes/T5_1TB
mount_apfs: unrecognized option 'remount'
mount_apfs: [-o options] [-u UID] [-g GID] [-n] [-c [-r] | [-C|-F <tier2 device>]] [-s snapshot] <volume | device> <directory>
mount: /Volumes/T5_1TB failed with 64
That may be a problem of it’s own, as I am not sure if it is possible to change VeraCrypt mount options.
Serious question…
Would a Windows server operating system and traditional SQL database be a better fit given your security needs?
I don’t think so.
I love DTTG and like DT.
But an SQL database would probably not execute files, just because it has executable rights
You keep missing something fundamental here.
DEVONThink is not executing the file. DEVONThink is telling the OS to open the file. Everything after that is out of DEVONThink’s control.
Opening files is a fairly basic piece of functionality that enables storage and use of files in DEVONThink that it doesn’t know how to open by itself. This ability to open files in their configured applications is very commonplace. FTP clients do it. IDEs do it. Finder does it.
And when you open a file, it’s up to the OS and the application actually opening the file to handle security, not the one triggering the action of opening it. The problem here is that your OS is configured to open the file in the shell, which does no security checking and blindly runs the script. As others have pointed out, you could have the same issue by opening any other file that can have executable content — an AppleScript, a web page, a PostScript file, a Word document, or even a PDF. (Yes, PDF malware exists.)
Should DEVONThink refuse to open Word and Excel documents, web pages and PostScript files by default? I think most users want to be able to store and use those kinds of files in DEVONThink, even if it’s putting them at some risk. Should it refuse to open files in external programs by default? Maybe, but I think that would break user expectations and make the application significantly less useful. If you disagree, well, you have the option in the preferences, turn the feature off.
You might say well, I want file opening, just not insecure files. In which case, think about what DEVONThink would have to do to meet your safety demands. It would need to have a list of file types to allow to be opened — and that list would need to exclude web pages, PDFs, Office files, and more. It would also need to have a list of safe applications, and refuse to open any file in unsafe apps — and the safe apps list would also have to exclude Office, Preview and Safari. That would break user expectations even more. Think about the support calls — “DEVONThink opens my other files but my Office files won’t open, why is it broken?”
No, the average user expects files to be openable even if they may contain executable code. In an ideal world we wouldn’t have so many apparently innocent file types that can contain malicious executable code, but sadly a lot of them were devised 30+ years ago before everything was on the Internet.
The fact that you had an extensionless file open in the shell by default is solidly an OS security problem. In fact, Apple literally just patched a related issue:
This shows that it is up to the OS to enforce security restrictions on opening files, and that Apple understands that.
7 Likes
Thanks for the link to the article. Interesting stuff for sure!
And you keep missing my point.
I am saying that this exactly is the problem!
DT should not just tell the OS to “do something”.
I am not surprised, that the Finder does this - as executing something in the Finder is the natural thing to do within Finder.
But DT should not just tell the OS to do that.
And your examples don’t help in this.
If you click on an Excel file, it does not get “opened”.
There is a defined connection between some file name endings and the respective Application to start (execute) which then in turn opens the file.
This is all fine and there are few problems with this.
But this is not the same as exectuing a file, just based on the fact that there is no apparent Application to start but the file based on a name extention, just because it has executable rights.
While is mostly OK for Finder, it is not OK for any Application.
DT should not do this and if you don’t understand the reasoning, I cannot help.
There is an apparent application to open executable files, namely terminal. There’s no fundamental difference from the point of the OS or DT between opening (!) a file in one app or the other. The security implications are the same as well, as has been explained by @meta already.
2 Likes
There is a difference.
DT is an Application to handle content, mostly bookmarks / URLs, text and MarkDown files, PDF and RTF file and files from Applications like Excel, Work, and so on.
So, finally, DT is a bookmark viewer, a text viewer, a MarkDown viewer, a PDF viewer and so on … either with internal previews or by starting a clearly defined App.
If there is not explicit mentioning of an Application to be started for any such file, DT should not just try to execute it, just because there are executable rights!
To make this more clear:
As soon as there is NO clear Application to be started for a file - which can be see as “Unknown format” error in the DT log - it should just not try to execute it, just because there are executable right.
This should be an easy fix and could help against most problems.
But to be honest, I don’t even see a need for DT to execute ANY file, even *.sh or *.bat
DT is not an Application-starting-engine! it just should not execute files at all.
So, the better fix would be to NEVER execute a file, as long there is not clearly an App that will be started to open a file, based on DT defaults or the file name extension, or as configured within DT by the user.
Over and Out from this topic.
Do as you wish, DEVON Technologies.
But it is sad, that I needed to discuss this at all.