IT'S NOT RECOMMENDED RUN ANY APP AS "ROOT" (Linux/macOS) or "SYSTEM" (Windows) FOR MANY MOTIVES!!!
READ THIS BEFORE: Do not run desktop applications as root. The Mac OS X frameworks are not intended to be used this way, and undesirable behavior will result (e.g, files/folders owned by root in the user's Library; process not responsive to "force quit"; potential security vulnerabilities).
Use Authorization Services to run specific, limited privileged operations as root.
In MSWindows is necessary create a "MANIFEST" file (like in Android applications) to elevate the privilegies for run an application as "Admin"... but in macOS I dont have it for test.
---> you can use as a sample to transpose to ObjectPascal (Delphi) app in C ... run as root user asking user/password prompt
Avoid root Running an application as root is not recommended because it dramatically increases the risk of causing problems with your Mac. The use of root should be limited to the smallest possible piece of code with strict controls in-place.
Applications are increasingly moving towards a fragmented design to avoid exposing too much power to code that does not require it.
A mistake in code running with root permissions is a security risk. A mistake in code without root permissions is much less capable of causing serious problems. There are edge cases but these are increasingly rare. The introduction of sandboxing and XPC are part of Apple's efforts to reduce the need to provide excessive authority to processes running on OS X.
Command Line Tools If you need to work with files as root user, use command line tools such as vim, emacs, or nano. These tools do not rely on the WindowServer and can happily be launched as root within another user session:
sudo nano <path to edit> Graphical Tools If you prefer graphical editors, use an editor that works with the design of Mac OS X. BBEdit is an excellent editor that will correctly handle editing root owned files.
When you edit a root owned file with BBEdit, a second process is used to bridge the permissions gap between you and the owner of the file. This process passes through Apple's sanctioned paths and thus ensures a predictable experience - hopefully across multiple major versions of Mac OS X.
Why? WindowServer Limits and Design Scope There are subtle technical problems with launching a graphical application within another user session.
The underlying technical problems stem from one user wanting to launch a graphical process within another user's session. Mac OS X's WindowServer was never designed with this as a goal. User sessions are extremely difficult to break out of even as root user – all for desirable security reasons.
Apple has dramatically improved the WindowServer design in the last few major versions of Mac OS X. It is now possible to have multiple users logged into different graphical sessions on one Mac through Screen Sharing. This seemingly simple improvement relied on a huge amount of behind the scenes effort from Apple's engineers.
However, Apple is unlikely to provide an easy way to cross launch applications as different users from within a single graphical user session. How would this benefit their customers?
If you want to explore this topic further, look for questions involving launchctl and running applications in other active user sessions.
----------------------------------------------
The higher the degree, the greater the respect given to the humblest!RAD 11.3