MACOSX: how to start daemon which need root privileges from cocoa application - macos

Conditions are the following: MacOSX 10.7 and Cocoa graphical application written in objective-c.
I am faced the following problem.
I can't start daemon application from /user/bin folder from my Cocoa application.
I know that I should have root privileges to do that.
I have installer, not *.pkg but manually written installer application. I need to start my daemons after installation process is finished.
How can I increase my privileges level in objective-c application?
I have this code.
But AuthorizationExecuteWithPrivileges call is deprecated.
We should not use it.
AuthorizationItem authItem = { kSMRightModifySystemDaemons, 0, NULL, 0 };
AuthorizationRights authRights = { 1, &authItem };
AuthorizationFlags flags = kAuthorizationFlagDefaults |
kAuthorizationFlagInteractionAllowed |
kAuthorizationFlagPreAuthorize |
kAuthorizationFlagExtendRights;
AuthorizationRef authRef = NULL;
OSStatus status = AuthorizationCreate(&authRights,
kAuthorizationEmptyEnvironment, flags, &authRef);
status = AuthorizationExecuteWithPrivileges(authorizationRef, tool, kAuthorizationFlagDefaults, args, &pipe);
The second way is to use privileged helper.
This way looks very complicated for my case.
I just need to start daemons after install.
Of cource I can ask user to restart mac. But i would like to avoid it.
Other possibility is SUID bit on the daemon executable file.
But it is not secure i think.
My question is:
Is there other simpler way to do it?

Well, there may be an answer here.
You need to:
Create a shell script with your operations.
Create an apple script NSString in which you request the shell script to be executed with administrator privilege.
Create an instance of NSAppleScript and execute the apple script.
Here are more details:
AuthorizationExecuteWithPrivileges is deprecated

Related

Why Xcode can not attach to some programs?

i had to reinstall my MacBook Pro. I have installed the newest macOS & Xcode version so
macOS Monterey 12.0.1 (21A559)
and
Version 13.1 (13A1030d)
I'm programming Audio plugins so to test my plugins I'm normally running a DAW (Digital Audio Workstation) in my case I'm working the most of the time with Ableton or Bitwig.
So if I start the debuging process, I get the follow error:
Could not attach to pid XXXXXX
attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries, when the attach failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)
If I have an eye to the console.app the the following lines:
[LaunchAttach] (3277) about to task_for_pid(2930)
error: [LaunchAttach] MachTask::TaskPortForProcessID
task_for_pid(2930) failed: ::task_for_pid ( target_tport = 0x0203, pid
= 2930, &task ) => err = 0x00000005 ((os/kern) failure)
macOSTaskPolicy: (com.apple.debugserver) may not get the task control
port of (BitwigStudio) (pid: 2930): (BitwigStudio) is hardened,
(BitwigStudio) doesn't have get-task-allow, (com.apple.debugserver) is
a declared debugger(com.apple.debugserver) is not a declared read-only
debugger
1 +0.000000 sec [0ccd/0103]: error: ::task_for_pid ( target_tport =
0x0203, pid = 2930, &task ) => err = 0x00000005 ((os/kern) failure)
err = ::task_for_pid ( target_tport = 0x0203, pid = 2930, &task ) =>
err = 0x00000005 ((os/kern) failure) (0x00000005)
I have done some research and found this:
Stackoverflow link about What does get-task-allow do
get-task-allow, when signed into an application, allows other
processes (like the debugger) to attach to your app. Distribution
profiles require that this value be turned off, while development
profiles require this value to be turned on (otherwise Xcode would
never be able to launch and attach to your app).
So there is nothing I can do to debug my programs with that software. Is that correct? :(
You can debug but you have to set the "Code Signing Inject Base Entitlements" to "Yes" for debugging
And then you have to add a provisioning profile. Go to developer.apple.com then select "Certificates, IDs & Profiles" to create a provisioning profile for the bundle ID you are testing.
This solved it for me on terminal
sudo DevToolsSecurity -enable
When you don't have access to the original source code or don't want to rebuild it, such as when developing plug-ins for another app (a DAW in your case), you can easily change the entitlements of the application as follows to enable debugging:
Read the current entitlements as follows (replace daw.app with the actual app name):
codesign --display --xml --entitlements daw.entitlements daw.app
Note: Run this in the Terminal app. It will create a file named daw.entitlements in the current folder. Run the command only once or delete any previously created daw.entitlements; otherwise the command keeps appending to the same file.
Open daw.entitlements in any text editor and insert the following text just before </dict></plist> at the end of the file:
<key>com.apple.security.get-task-allow</key><true/>
Note: If there’s already an entry with the same name, change its value from false to true instead of adding a new one.
Apply the new entitlements as follows (replace daw.app with the actual app name):
codesign -s - --deep --force --options=runtime --entitlements daw.entitlements daw.app
This should do it. In the unlikely chance that you already have a file named daw.entitlements in the same folder, use a different file name in all steps.
I tried all of these and had no luck until I figured out that I also had to disable SIP (system integrity protection) to attach to the audio server plugin I am working on.
Hopefully this helps someone to not lose a whole day on it as I did.

Under what conditions does RmGetList return 2 for the lpdwRebootReasons output parameter?

Background
I am designing an Inno Setup installer to install a Cygwin service, and I am puzzled by the behavior I'm seeing from the Windows Restart Manager APIs.
Specifically, when the service is running (started using the cygrunsrv utility), the RmGetList API function returns 2 (RmRebootReasonSessionMismatch) for its lpdwRebootReasons output parameter. This output parameter is an enumeration of type RM_REBOOT_REASON, and the description on MSDN for the RmRebootReasonSessionMismatch value is:
One or more processes are running in another Terminal Services session.
The Inno Setup log file contains lines like the following:
RestartManager found an application using one of our files: <executable name>
RestartManager found an application using one of our files: <service name>
Can use RestartManager to avoid reboot? No (2: Session Mismatch)
Inno Setup then proceeds trying to replace in-use files, as if Restart Manager was not used at all.
I am puzzled by this output value, because on two different machines I tested (Windows 10 1909 x64 and Windows Server 2012 R2), no terminal server/remote desktop users are logged on.
If I stop the service and start another executable (in the set of files to be replaced by the installer), RmGetList returns 0 (RmRebootReasonNone) for lpdwRebootReasons, and Inno Setup displays the normal dialog for in-use files and allows the user to select to automatically close them.
Process Explorer shows both processes (cygrunsrv.exe and the process it starts) running in session 0 and at System integrity level. Both are console subsystem executables.
Questions
Under what conditions does RmGetList return 2 (RmRebootReasonSessionMismatch) for its lpdwRebootReasons output parameter? (I'm trying to understand why this happens when the service is running.)
Does this value cause the entire Restart Manager session to fail, or can Restart Manager proceed even though it thinks applications are running in one or more different sessions?
For question 2, in the document RM_PROCESS_INFO
bRestartable
TRUE if the application can be restarted by the Restart Manager;
otherwise, FALSE. This member is always TRUE if the process is a
service. This member is always FALSE if the process is a critical
system process.
This value indicates if the application can be restarted by the Restart Manager.
For question 1, Note that services are running in session 0. If the process occupying the resource (registered in RmRegisterResources) is a service A, the RmGetList function which also running in the service process B will return lpdwRebootReasons = RmRebootReasonNone, bRestartable = TRUE.
But if A is not a service, then A & B are running in different sessions, lpdwRebootReasons = RmRebootReasonSessionMismatch and bRestartable = FALSE
other results:(B run with elevated privileges)
A & B is a console and in the same session:lpdwRebootReasons = RmRebootReasonNone, bRestartable = TRUE, ApplicationType = RmConsole.
A & B is a console and in the different session:lpdwRebootReasons = RmRebootReasonSessionMismatch, bRestartable = FALSE, ApplicationType = RmConsole.
A: service, B: console: lpdwRebootReasons = RmRebootReasonNone, bRestartable = TRUE, ApplicationType = RmService
(B not run with elevated privileges):
A & B is a console and in the different session:lpdwRebootReasons = RmRebootReasonCriticalProcess, bRestartable = FALSE, ApplicationType = RmCritical.
A: service, B: console: lpdwRebootReasons = RmRebootReasonPermissionDenied, bRestartable = FALSE, ApplicationType = RmCritical
According the document bRestartable depends on ApplicationType. And then, we can see that if the bRestartable = TRUE, then the lpdwRebootReasons = RmRebootReasonNone. But when bRestartable = FALSE, It depends on the other members RM_PROCESS_INFO.
A Clue from the RestartManager PowerShell Module
The RestartManager PowerShell module (special thanks to Heath Stewart) provides a simple PowerShell interface for the Restart Manager. My commands are as follows:
Set-Location <path to Cygwin root directory>
Start-RestartManagerSession
Get-ChildItem . -File -Include *.exe,*.dll -Recurse | RegisterRestartManagerResource
Get-RestartManagerProcess
Stop-RestartManagerProcess
These commands produce the following output:
Id : <process ID>
StartTime : <process start time>
Description : <executable started by cygrunsrv>
ServiceName :
ApplicationType : Console
ApplicationStatus : Running
IsRestartable : False
RebootReason : SessionMismatch
Id : <cygrunsrv process id>
StartTime : <cygrunsrv process start time>
Description : <description of service>
ServiceName : <service name>
ApplicationType : Service
ApplicationStatus : Running
IsRestartable : True
RebootReason : SessionMismatch
For some reason, Restart Manager sees the cygrunsrv.exe service process as restartable, but the executable it spawns as not restartable. (I am still curious about why this happens in the first place.)
An Imperfect Workaround Attempt
Based on this observed behavior, I first attempted the following workaround:
In the Inno Setup script's [Setup] section, set the following:
CloseApplications=yes
CloseApplicationsFilter=*.chm,*.pdf
RestartApplications=yes
The CloseApplicationsFilter directive specifies what files get registered with the Restart Manager. Note I do not specify *.exe or *.dll here; I want to manually specify only certain .exe files in the [Code] section.
Call the Inno Setup RegisterExtraCloseApplicationsResource function once for each .exe file in the setup that will NOT be spawned by cygrunsrv and put them in the RegisterExtraCloseApplicationsResources event procedure. Example:
[Code]
procedure RegisterExtraCloseApplicationsResources();
begin
RegisterExtraCloseApplicationsResource(false, ExpandConstant('{app}\bin\cygrunsrv.exe'));
end;
It's important not to register any executable spawned by cygrunsrv.exe or any of the Cygwin DLL files, because this will prevent the Restart Manager from taking effect in Inno Setup.
This solution is far from perfect, because executables normally started by cygrunsrv, if started separately, are not detected by Restart Manager (e.g., sshd.exe). For example, new SSH sessions are spawned in executables that the Restart Manager are not restartable.
A Better Solution
I've decided that a better solution is to detect any running executables from code and prompt the user apart from the Restart Manager functionality (which, simply put, doesn't work for Cygwin services).

How do I change window managers with Yocto Project tools?

My Intent
I have an image generated by BitBake on which I'm interested in changing the window manager to metacity or maybe something similar.
My Process
I've added require recipes-graphics/images/core-image-x11.bb into my core recipe, which provides a simple Matchbox terminal window but seemingly no other functionality. If I add matchbox-desktop and matchbox-session-sato, it adds a bit more usability but not what I'm looking for.
I've included the default package from the metacity_2.34.13.bb recipe from the meta-gnome layer from the OpenEmbedded Metadata Index in the IMAGE_INSTALL variable of my core image. This installs several components including a metacity command in /usr/bin. If I run that command, I get the following message:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
(metacity:1124): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' is not installed
Trace/breakpoint trap
I've navigated to /usr/share/glib-2.0/schemas and run glib-compile-schemas ., then run:
startx
metacity --replace
again. Now, the output is:
Window manager error: Unable to open X display
I haven't found a clear solution to this error which applies to my specific situation.
Update (2/29):
I may have now found a solution to this error, using these commands:
X&
export DISPLAY=:0
metacity&
At this point, I seem to be running something on one of my VTs. I can run demos like glxgears in that VT (glxgears is included in the mesa-demos recipe), but I don't know how to actually create a usable environment.
My question(s)
I'm not using much from meta-openembedded/meta-gnome (just metacity) or meta/recipes-gnome (adwaita-icon-theme, gnome-desktop3, gsettings-desktop-schemas and gtk+3), so am I missing some recipe which automates the addition of metacity?
(if not Question 1) How can I solve the error Window manager error: Unable to open X display?
The x11-common recipe adds a X session script that will run /usr/bin/x-session-manager: that is responsible for starting your desktop environment.
The way to implement a new session/DE in OE-Core is to use update-alternatives for "x-session-manager": see the matchbox-session recipe for the default implementation and mini-x-session recipe for an alternative.
mini-x-session might be modifiable for your needs so you don't need to write a new one: A /etc/mini_x/session file like this might do the trick:
# start any apps here, e.g. "my-desktop &"
exec metacity
Going from this (a running window manager) to "usable environment" might still be lots and lots of work, depending on your definition of usable.

Failed to load user32.dll when launching a process running in non-default desktop in Session 0 Winsta0

I have a Windows service (running on Windows Vista+), which needs to launch a normal GUI application. For some reason, I need to run the GUI application on non-default desktop (of course, since it's launched by the service process, it runs in Session 0, WinSta0, but not on the Default desktop).
The code looks like this.
// create new desktop
hDesktop = CreateDesktop(NEW_DESKTOP, 0, 0 ,0,
DESKTOP_SWITCHDESKTOP | DESKTOP_WRITEOBJECTS |
DESKTOP_READOBJECTS | DESKTOP_ENUMERATE |
DESKTOP_CREATEWINDOW | DESKTOP_CREATEMENU|
DESKTOP_HOOKCONTROL, &sa);
// create process of the normal GUI application,
// running on the new desktop, not the default one
STARTUPINFO si;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.lpDesktop = NEW_DESKTOP;
ZeroMemory(&processInfo,sizeof(processInfo));
BOOL bRet = CreateProcess(NULL, &commandLine, NULL, NULL,
FALSE, 0, NULL, NULL, &si, &processInfo);
TCreateProcess(...) method returns successfully, but the GUI application exits immediately after launching. With help from Gflags, I got following information.
LdrpInitializeRoutines - Error: Init routine 7595D711 for DLL "C:\Windows\system32\USER32.dll" failed during DLL_PROCESS_ATTACH
_LdrpInitialize - ERROR: Process initialization failed with status 0xc0000142
LdrpInitializationFailure - ERROR: Process initialization failed with status 0xc0000142
I searched for a while, seems it's related to security issue. I tried to grant all desktop related rights to current user, but it didn't help.
One thing may help. I noticed that there are a few DLLs were not loaded when running with SYSTEM account, the first one is uxTheme.dll.
Anyone has any idea why it doesn't work with non-default desktop, while working well with default desktop?
Thanks.
You need to use CrateDesktopEx and increase the size of heap -- the default is not sufficient even for the notepad.

Problem launching external executable from Win32 application

I am trying to launch an external application from within my Win32 application but it's failing. Following is the code I am using:
HINSTANCE instance = ShellExecute(NULL, _T("open"), _T("loader.exe"), NULL, NULL, SW_SHOWNORMAL);
if((int)instance <= 32)
{
_cprintf("Error = 0x%X\n", GetLastError());
return 0;
}
The instance value I get is 0x00000002 and GetLastError returns 0x2. The same code works when I try to launch other applications like iTunes.exe or cmd.exe. Does it has anything to do with external application? By the way, win32 application and loader.exe application are located in the same folder.
Any help would be highly appreciated.
Farooq-
Well, error 0x2 is ERROR_FILE_NOT_FOUND
Looks like it can't find "loader.exe"
Error 2 is "File not found":
http://msdn.microsoft.com/en-us/library/ms681382(v=vs.85).aspx
I'm guessing it can't find loader.exe.
Put loader.exe somewhere in the search path, or provide the full path. That is how to avoid this file not found error. Windows error codes are all documented on MSDN.

Resources