App Store–Compliant Methods for Uninstalling Root-Owned Applications

So, lemme see if I have this right:

• You’re building a Mac app.
• That ships on the Mac App Store.
• And you want to be able to let the user select another app…
• And then delete that app.

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, thats correct. basically its an uninstaller features to move the the app selected by user to trash.

OK.

Lemme start you out with a couple of links:

• On File System Permissions explains the different subsystems that all contribute to file system permissions on macOS.
• BSD Privilege Escalation on macOS describes the various ways to escalate privileges on macOS.

In this case you’re dealing with two types of file system permissions:

• App Sandbox
• BSD

You can get around the first with the coöperation of the user, that is, by having them select the relevant directory in an open or save panel. The issue you’re bumping into in the second.

Consider the permissions on the Applications folder:

% ls -ld /Applications 
drwxrwxr-x  89 root  admin  2848 Sep 17 14:06 /Applications

To remove application you need to be able to write to this directory. But you can only do that if you’re running as a user in the admin group. The directory is read-only for standard users.

To get around this you need to escalate privileges. However, the App Review Guidelines specifically proscribe that (clause 2.4.5(v))

I’m only aware of one exception to that rule, namely the NSWorkspace facility (see BSD Privilege Escalation on macOS for a link to the docs). However, the list of privileged operations it supports doesn’t include deletion.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Correct as you said for the first one I can get around, post which I am able to move app owned by user "sagarpurohit" to trash.

But for the ones owned by "root" is where I get permission issue even though I am member of admin.

sagarpurohit@Sagars-MacBook-Pro ~ % dscl . -read /Groups/admin GroupMembership
GroupMembership: root sagarpurohit _mbsetupuser

sagarpurohit@Sagars-MacBook-Pro ~ % ls -la /Applications
drwxrwxr-x@  5 root          wheel   160 30 Aug 11:03 Adobe Acrobat DC
drwxrwxr-x@  3 root          wheel    96 15 Jul 12:01 BBEdit.app
drwxr-xr-x@  3 sagarpurohit  admin    96 14 Sep 13:03 Brave Browser.app
drwxr-xr-x@  3 sagarpurohit  staff    96 10 Jul 18:02 Cursor.app
drwxrwxr-x@  3 sagarpurohit  admin    96 18 Sep 11:03 Firefox.app
drwxr-xr-x@  3 root          wheel    96 15 Jul 12:03 Speedtest.app
drwxr-xr-x@  3 root          wheel    96 28 Aug 22:49 zoom.us.app

I went through the links you shared but doesn't seem to be any solution there as I have access to directory for both read and write but this is more of who owns the app.

I was trying to change the user, for some app its does work but for other it says "Operation not Permitted"

But for the ones owned by "root" is where I get permission issue even though I am member of admin.

Right. That’s a weird edge case within the BSD permission model: To change the parent of a directory you need write access to the directory. Consider:

% mkdir -p parent/child
% sudo chown root parent/child 
% ls -ld parent
drwxr-xr-x  3 quinn  staff  96 Sep 19 21:51 parent
% ls -ld parent/child 
drwxr-xr-x  2 root  staff  64 Sep 19 21:51 parent/child
% mv parent/child .
mv: rename parent/child to ./child: Permission denied

It’s been a long time since I gave this any thought, but I believe it’s because, at least conceptually, changing the parent requires rewriting the .. directory entry [1].

However, this is by-the-by. Your app might be run by a non-admin user and they won’t be able to modify /Applications at all.

doesn't seem to be any solution there

Correct. There is no good solution this problem because:

• To get around these BSD permissions issues you need to escalate privileges.
• The App Review Guidelines specifically proscribe that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] That made a lot more sense with UFS than it does for a modern file system like APFS.