Is it possible to communicate with a launch daemon running as root and an application over XPC? When my daemon is running as my user I can communicate with it fine, when run as root it stops receiving my messages. Is this intended security inside Mac OS X?
I need to use low level xpc (for running on Lion as well). I know I can create a priviliged and signed helper tool that is running as root for my app. Will I be able to communicate with it with another process as well over XPC or sockets?
Thanks!
Small extract from my daemon code:
int main()
{
Logger::Start(Poco::Path::expand("/Users/Shared/Me/Service.log"));
Logger::LogInfo("Starting xpc_main...");
void* observer = nullptr;
CFStringRef observedObject = CFSTR("com.me.service.close");
CFNotificationCenterRef center = CFNotificationCenterGetDistributedCenter();
CFNotificationCenterAddObserver(center, observer, notificationCallback, CFSTR("ClientClosing"), observedObject, CFNotificationSuspensionBehaviorDeliverImmediately);
xpc_connection_t listener = xpc_connection_create_mach_service("com.me.service", NULL, XPC_CONNECTION_MACH_SERVICE_LISTENER);
xpc_connection_set_event_handler(listener, ^(xpc_object_t event)
{
// New connections arrive here. You may safely cast to
// xpc_connection_t. You will never receive messages here.
// The semantics of this handler are similar to those of
// of the one given to xpc_main().
Logger::LogInfo("Event Handler on listener is called");
eventHandler((xpc_connection_t)event);
});
Logger::LogInfo("call xpc_connection_resume...");
xpc_connection_resume(listener);
CFRunLoopRun();
Logger::LogInfo("Main Program is Exiting...");
return 0;
}
The problem is that CFNotificationCenterGetDistributedCenter works only on the same user, root user will not send message to other logged in users..
You'll need to switch to CFNotificationCenterGetDarwinNotifyCenter.
Please note however, that you can't pass any data using this center.
Related
First some background:
My setup uses a Service, which implements BeaconConsumer and binds to the BeaconManager. I have additional handling so when my app leaves the foreground, I move my Service to run in foreground, and when my app enters the foreground, I move my Service to run in background. That way, the persistent notification should display if and only if the app isn't displaying. In accordance, I am using the pattern here to tell BeaconManager I'm running this Service in the foreground, to allow for more frequent scanning. The link above isn't quite clear about this, but I believe this pattern should work without alterations needed on both pre-Android 8 as well as Android 8+. It shouldn't be strictly necessary on pre-Android 8, since the OS is more lenient. However, using this setup across all versions has the collateral benefit of ensuring that the OS does not kill the Service. If the app is in the foreground, the Service is background but has priority by virtue of the app, and if the app is not in the foreground, the Service is, and therefore has priority.
Now the problem: On pre-Android 8 devices, my Service is not seeing didEnterRegion called when the app is not in the foreground (but the Service is). It works fine on Android 8+.
some code snippets:
In my Service, set up the BeaconManager, set scan intervals
_beaconManager = BeaconManager.getInstanceForApplication(this);
_beaconManager.getBeaconParsers().add(new BeaconParser().
setBeaconLayout(IBEACON_PATTERN_1));
_beaconManager.setEnableScheduledScanJobs(false);
_beaconManager.setBackgroundBetweenScanPeriod(0);
_beaconManager.setBackgroundScanPeriod(1100);
Function in my Service I invoke to send the service to the foreground, and background:
private void sendServiceToForeground() {
this.startForeground(NOTIFICATION_ID, _notification);
if (_beaconManager != null) {
if (_beaconManager.isBound(this)) {
_beaconManager.unbind(this);
}
_beaconManager.enableForegroundServiceScanning(_notification, NOTIFICATION_ID);
_beaconManager.bind(this);
}
}
private void sendServiceToBackground() {
if (_beaconManager != null) {
if (_beaconManager.isBound(this)) {
_beaconManager.unbind(this);
}
_beaconManager.disableForegroundServiceScanning();
_beaconManager.bind(this);
}
this.stopForeground(true);
}
I can provide more code as requested. Not sure what all is relevant.
Calls to unbind() and bind() are asynchronous, so calling them one after another will be a problem unless you first wait for the unbind() operation to complete. This is tricky, because the library's BeaconManager does not provide a callback to tell you when unbind is complete (indeed, this is because the underlying Android service APIs also do not provide such a callback. You essentially don't know when the library's scanning service has stopped so you can safely restart it again in a different mode.)
It's a bit of a hack, but you might try adding a delay between unbind() and bind() to see if that makes a difference.
Apps handle GeoFence needs to receive PROVIDERS_CHANGED broadcast since:
Registered GeoFences will be removed when both 2 location providers
(network and GPS) are turned off.
When one of 2 location providers is turned on, app needs to register
GeoFences to work. This should be performed w/o asking user to run
my app again.
So my app has been registering its broadcast receiver in manifest. But it does not work any more in Android Oreo since PROVIDERS_CHANGED is not one we can make it work as before.
I can register broadcast receiver for that in app's activity or in service but it will quit (end its life cycle) sooner or later, then I need to unregister it. My app starts working by some events like GeoFence transition, but receiving PROVIDERS_CHANGED is critical to make it work.
I verified PROVIDERS_CHANGED can't be received by receiver registered in manifest in Android Oreo. Is there any solution for it?
#Tomcat and #Virat18 - I've come across a solution to the fact that you can no longer register a Broadcast Receiver in your Manifest to receive the PROVIDERS_CHANGED action Intent-filter in Android-OREO..
The solution? Simply register your BroadcastReceiver dynamically (from within your code), instead of from the Manifest.. Also, instead of checking for the hard-coded regex android.location.PROVIDERS_CHANGED, you should use LocationManager.PROVIDERS_CHANGED_ACTION (and of course import the LocationManager).
Here is an example of the Code I used to get this to work! (ex: from a Button Click):
public void buttonClick(View view) {
IntentFilter filter = new IntentFilter();
filter.addAction("android.location.PROVIDERS_CHANGED");
BroadcastReceiver receiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().matches(LocationManager.PROVIDERS_CHANGED_ACTION)) {
Log.i(TAG, "Action MATCHES LocationManager.PROVIDERS_CHANGED_ACTION!");
}
}
};
this.getApplicationContext().registerReceiver(receiver, filter);
Log.i(TAG, "RECEIVER HAS BEEN REGISTERED");
}
Also, don't forget to unregister the receiver in your code appropriately.
If you find this to be a good solution, please accept it as the Answer.
Happy Coding!
PS. This will continue to receive the broadcast from the background, even once the User leaves your Activity (presses the back-button, home-button, etc).. However, if the user closes your App from the Multitask button, it will no longer receive, so take note of that.
I am on XCode 9, OSX not iOS, Objective-C.
I have an XPC Service to talk to other applications.
XPC Services are completely new to me. I've read documentation and articles i found - still i'd need some help.
// NSXPC Connection stored as ivar
self.bridgeagent = [[NSXPCConnection alloc] initWithServiceName:#"com.myid.myapp.bridgeagent"];
self.bridgeagent.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:#protocol(bridgeagentProtocol)];
self.bridgeagent.exportedInterface = [NSXPCInterface interfaceWithProtocol:#protocol(bridgeagentProxyProtocol)];
self.bridgeagent.exportedObject = self;
[self.bridgeagent setInvalidationHandler:^{
NSLog(#"Bridgeagent invalidation handler!");
}];
[self.bridgeagent setInterruptionHandler:^{
NSLog(#"Bridgeagent interruption handler!");
}];
[self.bridgeagent resume];
The Service is called like this:
// openFile method is listed in corresponding protocol
[[self.bridgeagent remoteObjectProxyWithErrorHandler:^(NSError * _Nonnull error) {
NSLog(#"bridgeagent.openFile errorHandler: %#",error);
}] openFile:parameters withReply:^(NSDictionary *returnParameters) { // do something with result }];
The call works and the service does its job. However - now that the service works i want to dig into making it more stable (even if i don't face any issues right now).
Can someone explain to me
the difference between interruption and invalidation (don't get it when one or the other happens)
if there's a best practice to handle both cases
how to force both cases (for debugging)
Thank you for help
Answer to question 1:
[self.xpcConnection setInterruptionHandler:^{
// Connection interrupted. Backend (service) may have crashed.
// connection used to work but suddenly terminated
}];
[self.xpcConnection setInvalidationHandler:^{
// No one is listening. Is the backend running?
// connection cannot be established
}];
Answer to question 3:
interruption: make backend exit in the middle of a transaction (just before reply is sent)
invalidation: don't start backend (service) at all
Answer to question 2:
I have heard that in case "interruption" you should try to reestablish the connection. This can be useful when your service is a launch agent which gets restarted by launchd in case it crashed.
Actually in my program I don't act upon these cases but simply issue a warning message to the command line. My frontend is a cli program.
Alternatively you could log this warning in a logfile, for example with syslog. See 'man 3 syslog'. In my app I use my own logfile with configurable verbosity AND syslog.
kind regards,
Robert
I'm quite new to Firefox OS. At the moment I'm struggling with implementing some kind of service that listens for geolocation updates in the background.
If there are lots of apps running at the same time mine seems to be killed. While debugging with App Manager it disconnects silently.
I tried requestWakeLock('cpu') and the use of a Worker (as proposed in this thread) but without success.
Background services API isn't implemented, yet and will be available for certified apps only.
I know that there are non-certified apps like ConnectA2 that stay alive all the time so there has to be a way.
Could anybody give me a hint?
Firefox OS doesn't provide a way for you to run a service in the background intentionally, since the classes of the devices that we target (for example, the 128MB device) won't be able to support running apps constantly in the background.
There are alternate ways of implementing these kinds of services though. For example you can use the mozAlarm API in order to wake up your application at specific intervals, or you can use the SimplePush API which allows you to notify your app when a remote server initiates an event.
You can use Alarm API to prevent your app to be killed in the background.
Alarms wakes up the app at fixed intervals.
var alarmId = 0;
function setAlarm() {
function onAlarmAdded() {
alarmId = request.result;
}
var alarmDate = new Date(Date.now() + (60 * 1000)); // 60 seconds later
var request = navigator.mozAlarms.add(alarmDate, "ignoreTimezone");
request.onsuccess = onAlarmAdded;
}
function setHandler() {
function onAlarm(mozAlarm) {
// set next alarm
setAlarm();
}
navigator.mozSetMessageHandler("alarm", onAlarm);
}
function startAlarm() {
setHandler();
setAlarm();
}
function stopAlarm() {
navigator.mozAlarms.remove(alarmId);
}
I know the Brew application have 3 types: active, suspend & background. Launch one BREW application as active or suspend is very simple. I know in BREW2.0 and later version, there is a new application type can allow we create one application in the background. It will not stay in the application stack and change status by active or resume command. It will always stay in the background no matter what user command system received. In one of my small project, I need to create and launch one background application like this.
Unfortunately, I cannot find a simple example on Qualcomm or Google. Is there any programmer who has encountered the same problem?
Yes, you are right. BREW2.0+ do support background application.
When we initial a background application, just like other normal new application, it can be launched by the brew application interface directly. You also can launch it by ISHELL_StartApplet function.
When you want to put one brew application in the background, you need do it when handle EVT_APP_STOP event and must set dwParam to false. After handling EVT_APP_STOP by this, the application will be put in the background. And if you want to change it to normal application, you need call ishell_StartApplet function to active to itself again.
Example code:
typedef struct _bgApp
{
AEEApplet a;
boolean m_bGoBg;
} bgApp;
switch (eCode)
{
case EVT_APP_START:
if(pMe->m_bGoBg)
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
case EVT_APP_STOP:
if(pMe->m_bGoBg)
*((boolean*) dwParam) = FALSE;
return TRUE;
case EVT_USER:
if(pMe->m_bGoBg)
{
pMe->m_bGoBg = FALSE;
// make applet active
ISHELL_StartApplet(pMe->a.m_pIShell, AEECLSID_BGAPP); }
else
{
pMe->m_bGoBg = TRUE;
// trigger EVT_APP_STOP to send app to background
ISHELL_CloseApplet(pMe->a.m_pIShell, FALSE);
}
return TRUE;
}
There is a limitation of background application. You cannot change the screen or communicate with user directly. Developer should be careful on the memory used by the background application. This is very important.