In BigSur Beta, when I try to open a file using open file:////Users/<username>/Desktop/<filename.txt> the command is internally converted by prefixing the current working directory in terminal to the given value. For eg., if the current directory is "/Users", the command is converted into open /Users/file:////Users/<username>/Desktop/<filename.txt> This obviously gives an error unable to find the file. This happens even if I give a folder name instead of filename in file URI format. http scheme works fine and no prepending happens. For eg., open http://<url> redirects to safari cleanly Note: I understand from the man page, that whenever we give a non-absolute file/folder names to open command, it prepends the current directory to the given value. However this prepending should not happen in case the value starts with a file URI scheme (similar to how values starting with http is handled). This is working fine till Catalina and is present only in BigSur betas. Can someone confirm this behaviour.

The aim is to prevent even root users from uninstalling our app on their mac. Apparently, many security applications have this sort of functionality wherein a user(even with root privilege) can not uninstall or tamper with the agent on their machine. I tried tampering/deleting an antivirus app on Catalina but I failed and noticed a few interesting things: It has a kernel extension. But I can not remove the kernel extension(as root). &#9;&#9;#kextunload /Library/Extensions/***.kext &#9;&#9;(kernel) Kext com.***.kext did not stop (return code 0x5). &#9;&#9;(kernel) Kext com.***.kext can't unload - module stop returned 0xdc008017. &#9;&#9;Failed to unload com.***.kext - (libkern/kext) kext (kmod) start/stop routine failed. 2. The application is installed in /Library directory rather than the usual /Applications directory. &#9;&#9;drwxr-xr-x&#9;&#9;7 root&#9;wheel&#9; 224 Oct 28 14:40 xxxx The folder does not have any extended attributes. I can not delete this folder or any of its subfolders and getting permission denied error even as root. 3. The app has a bunch of launchdaemons but I can not remove them (again tried as root) #launchctl remove com.***.***. Not privileged to remove service. 4. Tried killing the processes, again operation not permitted. 5. The app comes with an uninstaller which can somehow uninstall the app, but it needs a special password (separate from system password) to be entered to work Many of Apple's own apps and services have this sort of behavior but they come with the system and are backed up by System Integrity Protection. How can a third-party app achieve this sort of behavior? This is not unique to this particular application but antivirus have similar sort of features. Any insight on how to achieve this.. Note: Ours is an enterprise app that will be installed on machines owned by the companies and managed by IT but end users will have root access on their machine.

We have an app which is distributed outside the appstore and the app is cleanly Notarised. When I try to open the app using open /Applications/<appname.app> I get the following error sometime The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x7ffa82413830 {Error Domain=OSLaunchdErrorDomain Code=125 "Domain does not support specified action" UserInfo={NSLocalizedFailureReason=Domain does not support specified action}}} This issue is intermittent and happens 20% of time. Our codesigning and Notarisation everything is clean. To give more context, the app comes with a native installer and in the Postinstall script we try to start the app by using open command, so that as soon as the installation completes the application comes up. Thats where we are running into this issue.   This does not happen till Catalina and we are seeing it only in BigSur latest beta. Any help is appreciated. Thanks.