After EVERY build I get asked to permit Area Learning. It seems like the Core can't tell I've already given the permission to the very same app before, although the bundle id didn't change. It's one of those small things that become extremely annoying after a while. Could this be fixed and permission evaluated based on the bundle id? (using Unity)
Does anyone have a temporary workaround?
You can use adb to install your code onto the device while granting permissions automatically.
$ adb install -g <package>.apk
The g flag grants all the permissions from the manifest.
Related
I'd like to prevent the use of the osascript terminal command by anyone without administrator access. I used to accomplish this by changing the permissions on the executable using sudo chmod 744 /usr/bin/osascript. The problem now (from what I understand) is that Big Sur does not allow changes to be made to the read-only system volume. I'd therefore like to find a workaround that retains this functionality ie. I don't want it to be possible to run this binary without the use of sudo. This has been a huge thorn in my side, and I don't want to have to resort to disabling SSV authentication in order to edit the system volume. If there's any way to just elevate the permissions needed then that would be perfect.
You could possibly achieve it writing your Endpoint security extension.
Subscribe to the ES_EVENT_TYPE_AUTH_EXEC and check the user from event parameters. Deny executing osascript from non root users.
It may sounds like a bit overkill, but there is no chance you can do it with SIP enabled in other way since big sur.
The only catch here is you need an apple developer account and request endpoint security entitlements from Apple. They could give it to you, if you desribe your solution in a proper way like security related project, but there are no guaranties.
Given the Covid situation I'm having to work with students remotely and they are all on different machines. Specifically I'm attempting to help a student to remotely configure her Mac Book to run Cordova but when she uses node to install it's adding it to her user folder and not to the root user folder.
Overview:
I can confirm she has 'allow user to administer this computer' toggled on for her account and there are now other users other than guest, so I would think she should have full admin rights.
She is using sudo to enter the command and it's asking for her password to confirm
She's installing globally using the -g switch
However after installation Cordova is showing in '/User/[name]/.npm/bin/cordova' instead of '/usr/local/bin/cordova' so subsequently the cordova command is not recognized.
I use Windows so I'm not as familiar with the MacOS/Terminal but I would think if I can't fix this I can just add her personal user folder to the environment variables but I'm not sure if that opens a new kettle of fish with regards to permissions.
So with that in mind, I'd rather not go down that road if there's a quick solution that I'm not aware of.
UPDATE: after some more looking around I found that the prefix for node wasn't set correctly. I'm still not completely sure why this computer was different but regardless setting the prefix corrected the issue.
I'm trying to run the setpriority command from my macOS app (objective-c). It never works and I'm assuming it is because the app is not being run as the root user.
I'm logged in to the admin account on my computer
I've tried opening the app with sudo
I've tried using chmod on the app
I've tried adding the app to the Accessibility list under Security and Privacy
Xcode version 9.2 (9C40b)
I would appreciate any help, thanks!
You want to run as root, or you want to run with sudo? There's a difference. Running as root is definitely not recommended, you will get strange behaviour from the system.
You wrote:
I've tried opening the app with sudo
That should work. How have you tried? You need to call the binary within the .app bundle. Running open against the bundle won't work.
e.g.
sudo ./Xcode.app/Contents/MacOS/Xcode
It's not recommended to run GUI apps on macOS as root. Instead, you should factor out the part of your application which needs root access into a separate helper tool, launch that tool as root using the SMJobBless() function, and then communicate with the tool using XPC.
Apple provides the EvenBetterAuthorizationSample example code to give a pretty good basic framework to work from.
EDIT: I decided to make my own authorization sample project a while ago that should be a little easier to use than the venerable EvenBetterAuthorizationSample. You can check it out at CSAuthSample.
I have a small diagnostic OSX program - a small menu-tray app - that I need to get to a customer. The program makes use of dtrace. As such, it has an auxiliary executable in it's MacOS directory with its suid bit set and ownership set to root:wheel. The helper's only role is to immediately exec() to dtrace with an included dtrace script.
My problem is that I can't figure out a good way to get this to the customer. Naively putting it into a .zip archive wiped out all the special permissions.
When I tried to put it in a DMG, the root:wheel ownership got reset to mine (ted:staff). I found that I was supposed to use diskutil to enableOwnership on the DMG to get it to start respecting file object ownership settings. So now I can see that inside the DMG, my helper program has the required root:wheel and +s suid permissions set.
Now, however, I've found that when I drag and drop the app bundle out of the DMG and onto the desktop, the permissions get reset again. Moreover, when I try to run the application from the DMG, it behaves as though the helper program doesn't have the suid bit set.
Stepping back from this a bit, I don't see why this should work at all. It seems like it would be a nasty and really obvious security hole to allow developers to distribute app bundles with the suid bit set like this.
So how is this done at all? Do I need a package installer? Will that preserve the suid bit? Can someone school me on how this is supposed to work?
You are correct that (if there were a simple way to do this) it would be a nasty security hole. You should never be able to create/install a setuid root executable without going through some admin authorization step. Indeed, you shouldn't even be able to create/install a file with ownership set to any user other than your own.
(Actually, there is an exception to that in 10.9: the App Store will allow you to install apps without admin rights. But that's considered relatively safe because Apple vets the apps before they're allowed in the store.)
The "right" way to do this is with a package installer. It can be set to request admin authorization for the installation, and use that to install files with whatever ownership and permissions you want (including the setuid bit).
Perhaps using a .tar file would work. They are very good for keeping all of the UNIX specific baggage like ownership attached to folders and files inside of them.
I have a daemon that needs to run as root and is started by launchd. This daemon needs to store some user supplied credentials so I have it writing them to the System keychain using SecKeychainOpen and similar functions.
I'm pretty sure that since this runs as root I have to use the System keychain (since using a user's login keychain is not correct as this doesn't run as a normal user).
My installer loads this into launchd using launchctl at the end of the install. The problem is that it doesn't actually start until after a reboot. I had OnLOad set as true in the plist, but it appears that when using the system keychain I need to the reboot for it to work.
I was wondering if anyone knows of some way to deal with this since it would be a much better user experience if a reboot was not necessary. So to be clear, can I programatically access the System keychain from a daemon using launchd without a reboot?
Thanks for any advice or ideas.
Since I eventually figured out that my problem wasn't what I thought it was at all, I figure I should put the resolution to it up here.
It turns out (despite what I read on a few sites) that it is perfectly OK to programatically access the System keychain with a daemon using launchd without a reboot. Just load the plist in the normal way (with root permission of course) and it all works.
My issue was the my postinstall script was never being run and was actually never even included in my .pkg installer when building on certain macs. Apparently, if you do not have PackageMaker.app installed, macports will still make a dmg with an installer for you, but the installer is a directory rather than the proper single file and it may lack certain parts (such as my postinstall script).
PackageMaker.app can be found on the Apple Developer site in the Xcode AuxTools package (it then needs to be put in either /Applications or somewhere else macports can find it).