App deletes itself when unzipped into /Applications as root
Opened this issue · 0 comments
A user filed this issue report against my app:
https://gitlab.com/gnachman/iterm2/-/issues/11033
I am able to reproduce it. Here are the exact steps:
- Download a zip file of my app (or any app that uses LetsMove) into
~/Downloads/app.zip
. - In Terminal,
cd /Applications; sudo unzip -x ~/Downloads/app.zip
- Launch the app and agree to move it to
/Applications
. - You are left with an empty folder.
I added some logging and here's what's happening:
bundlePath
is /private/var/folders/jk/2nklbh0x5ksc192jsm9nhnhc0000gn/T/AppTranslocation/F5172787-71B6-4B5D-A94D-E50E9670D998/d/iTerm2.app
IsInApplicationsFolder()
returns false
destinationPath
is /Applications/iTerm2.app
needAuthorziation
is YES
(destination folder exists and is not writable)
LetsMove attempts to trash /private/var/folders/jk/2nklbh0x5ksc192jsm9nhnhc0000gn/T/AppTranslocation/F5172787-71B6-4B5D-A94D-E50E9670D998/d/iTerm2.app
next.
All the methods fail, ending with the following applescript error dictionary:
{
NSAppleScriptErrorAppName = Finder;
NSAppleScriptErrorBriefMessage = "Not authorized to send Apple events to Finder.";
NSAppleScriptErrorMessage = "Not authorized to send Apple events to Finder.";
NSAppleScriptErrorNumber = "-1743";
NSAppleScriptErrorRange = "NSRange: {200, 39}";
}
But it succeeded enough to leave behind an empty folder.
% ls -laR /Applications/iTerm2.app/
total 0
0 drwxr-xr-x@ 2 root admin 64 Aug 6 10:57 ./
0 drwxrwxr-x 110 root admin 3520 Aug 6 10:57 ../
I don't think it'll be possible to detect that /Applications/myapp is the same as the translocation folder (maybe inode numbers would match? But I wouldn't count on it). One possible fix would be to rename the destination, copy the app over, and then delete the renamed folder. That has the downside that a failed move would leave behind a randomly named folder in /Applications.
Maybe someone on the project will have a better idea. I'm happy to send a PR once we have a plan in place.