I'm attempting to try out some modifications in SAP's Privileges.app. Unfortunately, their (understandable) Support policy is
This project is 'as-is' with no support, no changes being made. You are welcome to make changes to improve it but we are not available for questions or support of any kind.
Unfortunately, this app uses two constructs I've never come across before in my professional experience, an XPC service + helper (Launch daemon?) and a DockTile plugin. I'm having a hard time just fundamentally getting the app to work when launched from Xcode - it launches, but it seems that there are issues between (maybe?) sandboxing, signing and perhaps entitlements? I've updated the signing to use my own team, of course, and everything compiles/links/launches properly, but when the XPC service tries to install the helper tool it fails
2022-06-29 17:03:56.284544-0500 PrivilegesXPC[13079:128535] [logging-persist] cannot open file at line 45530 of [9ff244ce07]
2022-06-29 17:03:56.284570-0500 PrivilegesXPC[13079:128535] [logging-persist] os_unix.c:45530: (0) open(/var/db/DetachedSignatures) - Undefined error: 0
2022-06-29 17:04:21.060214-0500 PrivilegesXPC[13079:128537] SAPCorp: ERROR! Failed to connect to helper tool: NSCocoaErrorDomain / 4097
2022-06-29 17:04:31.471555-0500 Privileges[13064:127420] SAPCorp: ERROR! Error Domain=NSPOSIXErrorDomain Code=25 "Inappropriate ioctl for device"
2022-06-29 17:04:45.717751-0500 Privileges[13064:129162] SAPCorp: ERROR! Installation of the helper tool failed: Error Domain=CFErrorDomainLaunchd Code=4 "(null)"
As near as I can tell, the last two errors are thrown from a failure in
success = SMJobBless(
kSMDomainSystemLaunchd,
CFSTR("corp.sap.privileges.helper"),
self->_authRef,
&error
);
but I haven't been able to ascertain why this is failing. Searching for errors around Inappropriate ioctl for device has not been fruitful, unfortunately.
If there's anyone out there with some experience in dealing with apps using some of these more esoteric moving parts that can share some things to try, I'd be much obliged. Bonus points if there's any way to debug code running in a DockTile plugin - as near as I can tell, it's running in SystemUIServer, but I can't attach to that (even as root) from Xcode.
I think I've sorted out getting this running. Here's a few roadblocks I encountered.
SMJobBless has some very particular expectations around code-signing - you'll find references to this in some forum posts and there's a sample project that's also referenced with a utility script - which doesn't run on modern macOS because it's written for Python 2 -- which isn't installed by default anymore and a bit difficult to come by. But, after agonizingly converting Python 2-isms over to Python 3, you'll come to find out that that's not the only thing that's changed, a number of the tools (codesign and otool) don't output the same on ARM64 at which time you'll finally stumble across a kind soul that converted SMJobBless.py ... only to find out that it's not actually needed for this project?! Not sure if it's because the Launch Service is contained in the XPC and not the app, but either way - it seems to not be needed.
If you've run Privileges before, it'll have installed it's escalated helper, which will stand in the way of a local Xcode build copying itself over - which matters because of the aforementioned code signing. You'll need to clear away these artifacts
$ sudo rm -rf /Library/PrivilegedHelperTools/corp.sap.privileges.helper
$ sudo rm /Library/LaunchDaemons/corp.sap.privileges.helper.plist
Just deleting them isn't enough, it seems some sort of runtime launchd state needs to be wiped. It's unclear to me if some incantation of launchctl will clear this out, maybe an invocation of launchctl kickstart -k <foo> or something? I ended up rebooting and that seemed to do the trick anyway.
It seems like you need a particular signing certificate to allow the various signing validations that SMJobBless and the XPC communications are doing to be valid. Particularly, it seems you'll need a Developer ID Application, which happens to match what's encoded in the .xcodeproj pulled down from the GitHub repo. This means you can't enable Automatically manage signing as you won't get this type of certificate (as near as I can tell - please correct me if I'm wrong).
Once you've got all that sorted, since you aren't signing with the SAP developer's certificate, your certificate will have a different unique Team ID, so you'll need to update SMAuthorizedClients and SMPrivilegedExecutables, respectively, (look for 7R5ZEU67FQ and replace with your team ID) in
PrivilegesHelper/PrivilegesHelper-Info.plist
PrivilegesXPC/Info.plist
I think that's basically got it. Hope that helps someone else
Related
When running dbt deps, I get back this error message:
Running with dbt=0.17.0
Error sending message, disabling tracking
Encountered an error:
Unable to connect to registry hub
What's happening here, and how can I work around it?
First of all, it's worth understanding what's going on here. It looks like you're trying to install a package from the dbt hub site (hub.getdbt.com) — if you open up your packages.yml file, you'll find something like this:
packages:
- hub: package-owner/package-name
version: 0.1.0
When you run dbt deps (at a high level):
dbt sends a request to hub.getdbt.com
From hub.getdbt.com, a request is sent to GitHub to download the package.
The package is copied into your project
This error occurs if dbt cannot connect to the hub site after sending a network request repeatedly. First off, we recommend you retry the dbt deps command — sometimes it's just a blip in connectivity that goes away on the second try.
If the error persists, there may be a few different reasons for it:
hub.getdbt.com might be unavailable. This happens but is relatively rare. You can navigate to hub.getdbt.com to check if this is the case. Also check the Netlify status page to see if there are any issues.
GitHub might be down — you can check this by going to the GitHub status page.
Finally, it may be that a firewall rule or antivirus software on your computer is rejecting the request. Talk to your IT team to find out if this is the case and whether that restriction can be removed.
We generally recommend using the hub syntax for packages, however if you need to work around it, you can consider using the git syntax (docs) or installing the package from a local directory (docs)
I have developed an application for MacOS. I am including notarization process as part of its distribution. I have followed all the steps and I have run:
xcrun altool --notarize-app --primary-bundle-id "${APP_BUNDLE_ID}" --username "${APPLE_DEV_ID}" --password "${DEV_APP_SPECIFIC_PASSWORD}" --file "${DMG_PATH}"
Then I check notarization progress using:
xcrun altool --notarization-info "${notarize_uuid}" -u "${APPLE_DEV_ID}" -p "${DEV_APP_SPECIFIC_PASSWORD}
Output of it is:
RequestUUID: =<Request>
Date: 2019-05-26 09:40:34 +0000
Status: success
LogFileURL: <Log file>
Status Code: 0
Status Message: Package Approved =~ success ]]
Then I launch staple command:
xcrun stapler staple -v <dmg file>
It also ends with success:
The staple and validate action worked!
However when I extract the .app file and run:
spctl --assess --verbose ./macos/MyApp.app
./macos/MyApp.app/: accepted
According to the docs I have read it should say something like: “source=Notarized Developer ID”, right?
I am running this on MacOS Mojave 10.14.5
What am I missing??
Could someone help me?
Thanks in advance
In case someone faces the same problem I will post the solution to this:
First of all you must staple .app file not the dmg. This means you must extract the binary and staple it
Also in order to check if application has been notarized, in
`System Preferences - Security and Privacy`
Option Allow apps downloaded from: must have Apple Store and identifier developers option checked
Hope this helps
Both the app and the dmg may be notarized and stapled, seperately, one after the other. Try doing that and the error should go away.
Short answer
It could be due to an RPATH referencing a path outside the App bundle. Removing this RPATH would resolve the issue.
Inspecting log files
You can find extra information about the rejection (after trying to launch the blocked app) in the Console.app. Note that you should open the Console.app, before trying to open your blocked app, otherwise not all messages may be logged. You should look for process XprotectService in the logs of your device (i.e. choose your device in the left side bar of the Console.app). If the RPATH is indeed the problem, you should find a record like this:
XprotectService: [com.apple.xprotect:xprotect] File /path/to/your/executable/or/library failed on rPathCmd /rpath/causing/the/problem (rpath resolved to: (path not found), bundleURL: /path/to/your/bundle.app)
Inspecting these log files may give you a key to solve other issues too.
Note that I received the following information from an Apple engineer:
Gatekeeper does not inform users via UI about the specifics of the
error, though it is in the logs for developers to look at. The
notarization process is purely about a detecting malicious software
and does not replicate Gatekeeper enforcement. You still need to get
software notarized and test with Gatekeeper.
We are looking to provide better tooling for developers in the future
to pre-flight some of these common errors.
Contact Apple
If you are not able to solve your issue with the above information, you may want to contact Apple itself using the Feedback Assistant. They do not respond very quickly (~1-2 weeks), but the answers are rather to the point.
My Mac app copies files the user drags in. The app is sandboxed. I've got a bug now, which I can reliably reproduce in Xcode, but which I can't track down the source of.
When I add a certain number of files, the app suddenly stops being able to access the later ones. All the source files come one level down from the same parent directory, and all of the folders in between have the same permissions, verified with ls -l. The app retains an app-scoped bookmark to Destination Directory, which is accessed before creating .directoryName and beginning the file copy.
I get the error:
Error Domain=NSCocoaErrorDomain Code=513 "“Filename.ext” couldn’t be copied because you don’t have permission to access “.directoryName”." UserInfo=0x6080000eaf80 {NSSourceFilePathErrorKey=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUserStringVariant=(
Copy
), NSDestinationFilePath=/Users/Username/Desktop/Destination Directory/.directoryName/Filename.ext, NSFilePath=/Users/Username/Parent Directory/Subdir/Filename.ext, NSUnderlyingError=0x6080004567a0 "The operation couldn’t be completed. Operation not permitted"}
I have done the following while debugging:
Tried adding Subdir/Filename.ext on its own after quitting and relaunching, which worked
Verified (with lsof and Activity Monitor) that I'm not leaking file handles (which I know has caused similar problems for me in the past)
Verified with symbolic breakpoints that every call to -[NSURL startAccessingSecurityScopedResource] to is balanced with a call to -[NSURL stopAccessingSecurityScopedResource] (and their CF equivalents)
Determined that Filename.ext, and the other files that fail, succeed when added without the others
The same behavior occurs for Debug and Release builds, in and out of the debugger
I tried running as root, but my app won't run that way. When running in the debugger, I get an EXC_BAD_INSTRUCTION exception, and running it with sudo on the command line produces a crash (probably the same one)
The behavior seems to indicate some sort of resource leak, but it's not anything I've yet been able to detect. Any ideas what else might be causing this?
Update
I'm not ready to declare an answer, but I started to get these permission errors in a different part of my code, after a user has dropped files into the app. I noticed that a little ways up the logs, I'd see messages like the following:
Consume sandbox extension for itemIdentifier (1) from pasteboard failed!
Tracking down this error led me to a question someone else asked: Sandboxed Mac app exhausting security scoped URL resources
Unfortunately, the accepted answer says (paraphrasing) "tough noogies". It seems that Cocoa and the sandboxing mechanism themselves are leaking the security-scope tokens (though I can't verify with symbolic breakpoints and know of no other way to check). After a certain (unknown) number of file operations on sandboxed files, you'll start getting this error, and the only solution is to quit and relaunch.
I wish there was at least some way to prompt the user to relaunch when it gets close, but I'm not sure of any way to measure how many of these handles are in use. Or, even better, if I could manually clean up after I finish handling the dropped files, but I'm not sure how that would work, since I need to use the NSFilenamesPboardType pasteboard type to get multiple files' paths. I tried creating NSURLs from these and stopping security scope access, but that had no effect.
Update 2
I submitted a DTS ticket for this, as it's affecting users and there is no clear workaround. I'll update the question (and maybe give an answer?) as I find out more.
Response from Apple's DTS team
Apparently, this is a known issue, with no available workaround. I submitted a Radar: rdar://20652066, if you'd like to dupe it.
This was fixed in an El Capitan (10.11) release (possibly the first, but I'm not sure). When I built my app against the updated SDK, the behavior returned to normal.
I'm experiencing a problem that I could not find a solution for yet.
I use Test Complete to automate some GUI related scenarios for an app. I developed some scripts that were working at some point in the past. After a few months I got back and tried to run one of the scripts. The script failed with the following error while it was executing a ClickCell operation on a grid object.
An error occurred.
Possible reasons:
1. The application stopped responding.
2. The application was compiled incorrectly (see the Open Applications topic in the help system).
3. An error occurred in TestComplete.
Technical information:
379 0x80070057 (The parameter is incorrect.) .
Tested object:
...
I executed the same script on another machine with another Test Complete installation and it worked. So I guess it's not the target app that is the problem.
I checked solutions on the web for this issue, but nothing worked. I cleaned up the temp files in all the locations I could find in this answer. The behavior was the same.
So I guess it might be something related with the Test Complete installation. I tried reinstalling it a few times, but it didn't do the trick.
I then used Dependency Walker (as suggested somewhere on the web) on testcomplete.exe and found that there are some dlls that are missing from the Bin directory of Test Complete. Could they generate this error? If yes, how can I get them? As I said, I already re-installed the app a few times.
Did anyone bump into this while working with Test Complete? Is there any .net temp location that I should clean?
I am trying to make an embedded Linux for a SuperH processor board. I am using the Buildroot 2012.2 toolchain with uClibc.
All compiles fine but when I try to run some of the BusyBox applets (for instance 'ls' or 'mount'), I get an error like this:
ls: : Unknown error 2
For 'ls' in particular it writes this error number-of-files-in-folder times.
Do you have any ideas what might be causing this? No one on the internet seems to have the same problem and I am crawling the configs for several days without luck.
I believe the error might be caused by misconfigured uClibc but it is just my guess.
Thanks.
EDIT:
I enabled several error message options in uClibc and now I get "no such file or directory" error.
I will answer my own question.
The first and most important problem was, that I have over-optimized uClibc so all reasonable error reports were not included. If you are reading this and have same problem, switch error messages on. They are quite small and very useful.
After resolving human readable error reports, I realized, that the putchar function was disabled. Enabling it solved the problem.
To future generation I advise extreme caution, which features of uClibc you decide to disable, unless you want to spend several days finding an unexpected bug.