Account Locked

So the System was not popping up Do you want to provide access to the Desktop etc folder etc. in this condition to the Standard User. Where did the Message/Window to confirm access to the folder vanish to? There are more questions on this below, but I suspect what's going on here is you have two plugin instances (because Photoshop is running as a separate process in the two different login sessions) which are both talking to the same background process. I don't know how you ended up in that state, but it's impossible for the same process to work in different login sessions. The moment the Admin User was physically logged off the Mac, everything started working for the Standard User even under Screen Sharing. This makes us wonder if this is an edge case macOS bug? No, I don't think this is a macOS bug. Questions I need answered here are these: How are you doing this? Is the background app a launch agent or something else? Also, what exactly is your background app? Is it a true (presumably faceless) app that ru

First of all, thank you for the answers. We went back and figured exactly what was occurring and the condition. Everything we did when I posted my original message was on a newly setup M4 Pro Mac with 15.5 as we like to test things continuously. To investigate further we setup a VM with the same conditions Admin user/Standard user. On the VM everything was working under the Standard user account wherein the System did pop up message saying Do you wish to grant ABCD access to the Desktop or Downloads etc folder. We grant access and our plug-ins work as expected. We went back to the actual M4 Pro machine and understood exactly what was occurring. The Admin user was Physically logged into the system though the GUI was not in use. But the Standard User for testing purposes was logging in via Screen Sharing to the M4 Pro Mac. So the System was not popping up Do you want to provide access to the Desktop etc folder etc. in this condition to the Standard User. Where did the Message/Window to confirm access t

First off, ruling an issue out here: However, when our tool is installed from a Standard Account, the macOS messages asking for confirmation to access the Desktop or Documents or Downloads folder don’t appear and access to the file/folders is denied. Does your app include all of the relevant tcc strings (NSDesktopFolderUsageDescription, etc.)? Also, one thing to be careful of here is that there are a bunch of heuristics in this system that control how/when these are presented, which can make knowing why something is working a particular way difficult to determine. When you're looking closely at an issue like this, I'd always suggest working on a totally clean machine*, not your normal development machine. *VMs are handy for this, as you can get the system to a fully configured state, then duplicate the VM image so you can always start over from the same exact starting point. We install a Photoshop plug-in and it’s mainly a UI which then executes a background app containing the business logic to read/

There, that's better... I'm unaware of any difference between admin and standard users with respect to these kinds of permissions. Your description of the behaviour when installed in a standard account is how I would expect these apps to function normally. I think the most likely explanation is that most users (and developers and testers) use admin accounts and they haven't made a habit of resetting these permissions to test onboarding and initial setup. Full Disk Access is sometimes a solution. But that isn't a meaningful improvement over the default process. The user still has to manually go into System Settings. And in some cases, when people try to run these tasks as root, it can make these problems even more difficult. The root cause is attempting to use separate backgrounds tools. Why not just put all of the logic into the UI? Or take that further and make your app more stand-alone, with the plug-in being less important? I'm afraid there aren't any ways to technically work around the p

i cannot work with EndpointSec without com.apple.developer.endpoint-security.client in extension.entitlements approved by Apple in my dev account???

[quote='849612022, ravi-kb, /thread/793566?answerId=849612022#849612022, /profile/ravi-kb'] I am also facing same problem. Please provide solution. [/quote] Dude, using a second account to pretend that you’re a different developer is uncool. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='793566021, ravikaradbhajne, /thread/793566, /profile/ravikaradbhajne'] [my app] needs to install and trust a root certificate … programmatically. [/quote] On iOS and its various child platforms, there’s no supported way to do this and never has been. The situation on macOS is more nuanced. Historically you could do this with keychain APIs. However, we’ve since added security hardening that prevents this. There’s now no supported way to achieve this goal. In this respect macOS now follows iOS: In managed environments, you can install trusted roots via MDM. Otherwise, the system trust store is under the control of the user. I suggest you rethink your product plans to account for this policy. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Synopsis We are having exactly the same problem as the original poster here. I talked with Apple Support and they recommended I post in this forum to try to get input from others who may have encountered the same issue and maybe can explain what we are doing wrong. We are an MDM Vendor and provide an MDM management solution to Enterprise customers. While the Apple Business Manager does provide a control to disable activation lock on a specific device, and that DOES work, we need to be able to do this through an API as our customers’ help desk personnel will likely not have Device Enrollment Manager Roles in Apple Business Manager to remove the lock through the Apple Business Manager API. We are following the instructions at https://developer.apple.com/documentation/devicemanagement/activation-lock-devices We have enrolled our device through Automated Device Enrollment and the device is properly represented in Apple Business Manager. We were able to successfully enable the activation

I was on vacation last week and am still catching up, so my response here will not be complete. So, first and foremost, do you have these issues with our sample project? If the app does not receive the keep-alives from our local server within 5s, it tears down the connection and establishes a new one. Ruling an issue out, how frequently is the server emitting its keep-alive? One slightly less obvious detail here is that in a naive implementation where one device emits a keep-alive every 5s and the other requires a keep-alive every 5s, you can create a situation where what you're actually depending on/measuring is the consistency of latency between the devices, NOT the reliability of the connection itself. Putting that in concrete terms, imagine a connection with a latency of 2s (I'm using a very large latency to make the math simpler). Your communication then looks like: Time 0s-> Server sends. Time 2s-> Client receives. Next reply must arrive at 2s + 5s-> 7s. Time 5s-> Server sends. Time 7s->

Good guess, but that wasn't the issue, even though it would have made a lot of sense. It's unfortunate I left that part of the code in there, but the user actually tested my App Store app with and without unlocking locked files (the app contains a switch for that), which didn't help, and they sent me plenty of screenshots and videos which show that the files are not locked. So, I took another pass at this and I think I found the problem. There is actually a known bug (r.129627798) similar to this in our smb server that was fixed in macOS 26. Basically, the way delete works in smb is that the client accesses the file with a DELETE_ON_CLOSE option, then closes the file to trigger the delete. The server tracks open file references and then deletes the file when the count reaches 0. Unfortunately, there was an issue in our file closing logic which could cause the server to keep the count high longer than it should, leading to the problem you're seeing. I've mentioned that this was happening on o

Thank you Quinn for the insights! It's quite a coincidence indeed, I hadn't seen that other thread yet! I think I found that ancient Q&A while searching the Documentation Archive for Authorization information (or maybe on a comment you left in an older thread). Before filing a bug report, I'd like to clarify whether this is actually a bug or simply a missing feature. What puzzles me specifically is the behavior of Activity Monitor.app: Even when I use rights that are explicitly configured as non-shared (like authenticate-admin-nonshared), Activity Monitor still appears to inherit the credentials. I also tried to configure com.apple.activitymonitor.kill with a timeout of 0, but that didn't help. The only way I've found to prevent this behavior is when the original application explicitly calls AuthorizationFree() with the .destroyRights flag. However, newer versions of System Settings don't have the lock icon you mentioned, so they appear to not be destroying these rights (even if I close the windo

Regarding the big picture issue here, I believe that this is working as designed [1]. If you’d like to see that change, my advice is that you file a bug report explaining your concern.. Please post your bug number, just for the record. [quote='793415021, ss_couto, /thread/793415, /profile/ss_couto'] What exactly is the authorization session mentioned in /System/Library/Security/authorization.plist? [/quote] This refers to the security session, which is roughly equivalent to the login session. [quote='793415021, ss_couto, /thread/793415, /profile/ss_couto'] QA 1277 [/quote] It’s hard to believe that this is the second time that truly ancient Q&A has come up in the past few weeks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] If you look at the design of System Preferences on early versions of Mac OS X, various panels have a lock icon. That reflects the state of the admin credentials. If you’re logged in as a standard user a