{"id":37108,"date":"2022-09-22T15:49:16","date_gmt":"2022-09-22T19:49:16","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=37108"},"modified":"2022-09-23T07:51:37","modified_gmt":"2022-09-23T11:51:37","slug":"terminal-and-full-disk-access","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/09\/22\/terminal-and-full-disk-access\/","title":{"rendered":"Terminal and Full Disk Access"},"content":{"rendered":"

Jeff Johnson<\/a> (tweet<\/a>):<\/p>\n

Many expert Mac users grant Full Disk Access to Terminal app, because the permissions dialogs quickly become very annoying when you try to do things in Terminal, as we’ve already seen above.<\/p>

[…]<\/p>

What you may not realize is that if you grant Full Disk Access to Terminal, you thereby provide Full Disk Access to every unsandboxed app on your Mac too! And how can this be? The reason is that unsandboxed apps can open executable shell scripts in Terminal, and those scripts will execute with the permissions not of the opening app but rather with the permissions of Terminal, i.e. Full Disk Access.<\/p>

[…]<\/p>

If you think the solution to this problem is simply to withhold Full Disk Access from Terminal: it’s not that simple! Every unsandboxed app effectively has all of the permissions of Terminal, whatever those permissions happen to be.<\/p><\/blockquote>\n\n

I don’t understand why Terminal executes shell script files in the first place. It doesn’t even prompt to confirm. Aside from the security implications—for what I think is not a commonly used feature, anyway—it also means that I sometimes execute a script by accident, double-clicking and expecting it (because of the icon) to open in a text editor.<\/p>\n\n

Quinn the Eskimo<\/a>:<\/p>\n

\n

MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any<\/em> script could do that.<\/p>\n

The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts.<\/p>\n<\/blockquote>\n\n

Sheldon15<\/a>:<\/p>\n

\n

I find it’s a little backward approach to not have a robust way to test for FDA and instead handle errors resulting from the lack thereof. The problem is that sometimes you can’t distinguish errors resulting from the lack of FDA and other kinds of errors. Or you have a lengthy operation that you know will fail or will be incomplete without FDA and you want to tell the user in advance.<\/p>\n

In my case, my app estimates size of a directory. Some subdirectories inside of it will not be counted due to the lack of FDA, and the overall size will not match Finder’s estimation. The scope of all folders protected from FDA is not clearly defined in the documentation, so I will not be able to detect when I have a lack of FDA or it’s a different kind of error. I can guess and recommend the user to add my app to FDA, but it’s confusing if he’s already done that and still sees the recommendation.<\/p>\n<\/blockquote>\n\n

John Daniel<\/a> (in 2019<\/a>):<\/p>\n

Full Disk Access isn’t very reliable either. You can do everything right and it still doesn’t work sometimes. You have to budget for this and provide documentation on how to remove an app, restart, re-add, and fallback to tccutil<\/code> in the Terminal when all else fails.<\/strike><\/p><\/blockquote>\n\n

Previously:<\/p>\n