ls Desktop Operation (still) not Permitted

Question

Level 1

12 points

ls Desktop Operation (still) not Permitted

I have a brand new Mac Book Pro with the M1 chip. I have installed a few apps (homebrew, docker, IntelliJ, nothing too weird) for my job. I probably *should have* tried this after unboxing, but who knew!?? Opening a terminal and cd'ing to the Desktop, the ls operation (that's ell ess) fails with "Operation not permitted". I know enough to intuit that this is odd behavior, the very first time. But trying to ls the Desktop folder form the containing folder, using sudo, switching to root via su (something I have not had to do for YEARS) and getting the same result, DROVE me to Google for answers. And that led to this forum, where it was asked by th3rt10n about Catalina in 2021.

I actually started with Big Sur, and within weeks was pestered to upgrade to Monterey, which I did. So the machine has received a fair amount of use. But not a fanatical amount. I have a feeling if I had tested this upon unboxing It would have behaved identically. There was a response to th3rt10n's question, provided by MrHoffman: "System Preferences > Security & Privacy > Privacy > select Full Disk Access on the left, add Terminal.app on the right, and see if things work better."

Of course they would. Security holes, anyone?

So. Not gonna do that. I would like someone who really knows what's really going on (someone in the assembly line?) to explain why this would be this way. Why I can ls every folder in /home/me except Desktop.

It should not be this way. Not even in theory. If you have something to hide, there are plenty of better places to do so. If you're looking to open up a sea of Mac security holes, then well done! Lots of folks will see this (extremely suspicious) problem, and an answer that really fixes the problem and move on.

I don't get it. Please help me get it. Thank you.

Posted on Feb 5, 2022 10:16 AM

Reply

Answer 1

Top-ranking reply

James Brickley

Level 5

5,686 points

Feb 5, 2022 3:22 PM in response to M68K

The functionality is called Privacy Preference Policy Control (PPPC) and was added in macOS 10.14 Mojave to protect the user from cross-application data requests such as accessing user and system resources without user approval. Desktop, Documents, Contacts, screen capture, camera, microphone, and input monitoring are protected. This includes scripts running behind the scenes. PPPC was further enhanced in Catalina and Big Sur but all the changes pertained to IT departments controlling Macs via an MDM (Mobile Device Management) server.

When you open Terminal the first time and try to list or change directories into your Desktop, Documents, & Downloads. you will be prompted to allow or deny it. This adds an entry in System Preferences -> Security & Privacy -> Privacy -> Files and Folders. If you allow it the Terminal will be added to the list and a sub-item "Desktop" will be checked. If you didn't allow it then an entry is still added to Files and Folders but it will be unchecked. You can remove the App entirely from the list and that resets the prompts and you'll see them again. That means you must have granted access to Documents and Downloads but not Desktop.

When you installed Homebrew and updated it likely prompted for access to these folders. This is annoying for professionals and wasn't the case with earlier versions of macOS. Therefore, adding Terminal to Full Disk Access and Developer Tools (if you have that one) is no different than it has always been. So not an incredible security risk. Any scripts which you didn't initiate inside Terminal that might try to access these locations will still be blocked unless the parent process is whitelisted via a Configuration Profile normally managed by an MDM (Mobile Device Management) server or from Apple Configurator. Even if you whitelisted Terminal with Full Disk Access that only applies to you running Terminal on the console it doesn't apply to scripts running under the hood behind the scenes initiated by a different parent process.

Prior to PPPC Apps had full access to the content of these folders in the past and some developers were abusing it. Similar security was increased on iOS before it made its way to macOS. Let's say you install some App and it's asking for access to your Contacts and you do not wish to allow it. You now have the option to prevent it. An App may have a legitimate need to access your Contacts but who is to say if your contacts won't be uploaded without your knowledge to a cloud backend? You have no idea so this helps you have control. When I say various Apps abused their access to data, I am serious. Lots of Apps on iOS and macOS where capturing all sorts of private data from users.

There are some other system file locations protected which is why you might want to enable Full Disk Access to Terminal. As someone using Homebrew and developer tools you should add Terminal to Developer Tools as well. If you decide to use iTerm you should add that as well. Sooner or later you are going to get into a scenario where you are denied access or cannot list folder contents, etc. and you won't know why necessarily.

Reply

Answer 2

Feb 6, 2022 6:04 AM in response to M68K

The OS will place a shortcut to "Relocated Items" after a dot release of macOS, etc. The protection is about user privacy so read access and even listing files are blocked but write is allowed for legacy edge case reasons. Read access is protecting your privacy but there are many edge cases where an App or IT needs to write to the folders. Some an engineer cannot predict so that is likely why write is allowed.

Apple did publish a detailed description of all their security measures in hardware and software. Click on the Table of Contents.

Apple Platform Security

https://support.apple.com/en-jo/guide/security/welcome/web

Reply

Answer 3

M68K Author

Level 1

12 points

Feb 6, 2022 4:20 AM in response to James Brickley

Thank you for the volume of helpful information. Perhaps you could clarify...

In this situation:

I was never prompted

Someone probably was (IT, etc)

But why on Earth would they say "no" to the Desktop?

It just doesn't make sense!

And further,

I *do* have write access to Desktop! So, if I was feeling' malicious, I could go to town. Dig:

Documents % cd .. 
~ % cd Desktop
Desktop % touch nono
Desktop % nano heapBigTrouble
Desktop % ls
ls: .: Operation not permitted
Desktop %

Trust me, I was able to write and save heapBigTrouble to the Desktop.

And finally, has Apple Dev not fully grasped the concept of root?

root is supposed to be "You're sure you know what you're doing?!!" dangerous.

And yet not even root, itself, had "ls access" to Desktop?

But in UserLand, without being prompted for my administrative authorization, I can fix this? (I just did)

I comprehend locking (some) things down for better security, I do. I respect and appreciate that.

And when Angry Birds asked for full control of everything on my Android smart phone, my response was,

"you'll get full control of this smart phone when you pull it from my cold, dead fingers."

So, roger the opportunistic apps. It just seems like there is a slight disconnect between what

gets clicked on, and olde world concepts like "I am root. Obey my command, immediately".

I understand that this is a difficult thing to get right (gui, root).

For the record, I did not choose to give Terminal Full Disk Access. A little bird told me not to.

But I am grateful for your detailed and clear explanation. Actually, I think this *did* solve my question!

Thank you, James Brickley! I hope others will benefit from your download of knowledge.

Reply

ls Desktop Operation (still) not Permitted

Similar questions