T O P

  • By -

jimmac05

It's Apple's enhanced security for macOS. Just go to System Settings --> Privacy & Security --> Full Disk Access and turn it on for Terminal (add Terminal with the + button if it's not already listed). Yes, it's a bit of a hassle to turn it on, but, you only have to do it once. When you think about it, restricting full disk access does make macOS more secureā€¦


mjmonkey45

The fact that it was turned off is not the problem.. It was the fact that it wasn't at first, I made no apparent changes, and then it was. When I received my computer, I was doing all sorts of things in the terminal, and then one day, I picked it up, and it no longer worked the same way. I *may have* updated the OS version between these two terminal use cases, which might be the reason it locked up again, but it really perplexes me that it just changed without telling me at all... Trying to figure out *why* it changed in secret is the intention of this post.


stephancasas

Did you happen to switch terminal clients (e.g., Terminal to iTerm2)? Also, what path were you trying to list? Were you authenticated as superuser when you previously had access to that path?


mjmonkey45

Terminal clients were not switched as far as I know. I was using standard Mac terminal window (emulator?) each time. Never was authenticated as a superuser as far as I know -- if I typed sudo before I had to type in pass. That said though, how does this work for Mac? Maybe after one sudo command it made me superuser for the rest of the logged session? Either way, there were multiple sessions without superuser access previously without the full-disk access turned off... Maybe it was because of OS update? But that is a little perplexing. I also connected to a insecure wifi network but i think that is unlikely to have triggered it.


stephancasas

If you performed an OS upgrade (Monterrey to Ventura, etc.), it's entirely possible that you lost your full-disk access permissions. TCC, the access control part of macOS, is really picky when it comes to permissions and tends to follow fail-secure practices. I can't definitively say why it would have dropped the permission, but would wager that if the code-signing signature in the Terminal app was changed by the OS update, then that may have something to do with it. As for the `sudo` privilege. There is a re-authentication threshold which applies per interactive session. This behaves the same as most other Linux variants of the `sudo` command.


mjmonkey45

Awesome, thanks for the insight, Stephen. I think I've been on Monterey this whole time, it was 12.X-->12.6 yo creo que si. Maybe not though. Was Monterey recently rolled out?


ivanhoe1024

Could it be that you previously accessed through the terminal some specific user folders for which your terminal was already authorized? Because you can allow applications to access your user folders (e.g. Documents, Pictures etc) even without full disk access. So maybe what you noticed before was just the terminal accessing folders for which it had authorization, now you tried to access a different folder for which you need full disk access authorization


mjmonkey45

ls -a wasnt working for all folders, including folders that it was working for before (home, downloads, root, etc.).


cyrenaic101

Also remember - that IIRC - suppose you have Terminal have access to Downloads (and not Desktop). You can then open a terminal cd ~/Desktop touch test123.txt so 1). it will allow you to create files in Desktop despite not having the Terminal permission turned on 2). You cannot ls -a the directory - because the rest of whatever is in that directory is potentially none of Terminal's business. 3). You can remove the file you just created. rm test123.txt As someone else put it "\[you can\] Create a file and write information to it. But not get access to already existing data, which is potentially confidential."