Stop working on macOS Ventura

[mliza]

There are some issues with permissions on Ventura, for some reason is not detected by the location services hence it can not be allowed to run.

[alexmyczko]

somehow it works for me on Ventura...

[jtsigros]

I have the same issue in Ventura:
CoreLocationCLI: ❌ Location services are disabled or location access denied. Please visit System Preferences > Security & Privacy > Privacy > Location Services

Even thou location services are on.

[IoannisTM]

I have the same issue in Ventura: CoreLocationCLI: ❌ Location services are disabled or location access denied. Please visit System Preferences > Security & Privacy > Privacy > Location Services

Even thou location services are on.

same here

[JayBrown]

Same in Monterey. Managed to solve it by removing/unticking the old CoreLocationCLI (at the old Caskroom path) in Privacy > Location Service … then removed the quarantine XA from the new version, executed it, and it worked fine. (You might retick CoreLocationCLI again afterwards in System Preferences, but it worked anyway.)

EDIT: the unticking-reticking thing seems to be important. I did a test after copying CoreLocationCLI to a different path, which had been in use before, and I needed to untick/retick before it worked again.

Nota bene… there is also a way to do this all with AppleScript, in case you are distributing scripts to systems that might not have CoreLocationCLI installed.

osascript 2>/dev/null <<EOG
use framework "CoreLocation"
use framework "Foundation"
use scripting additions

property this : a reference to the current application
property nil : a reference to missing value
property _1 : a reference to reference

property CLLocationManager : a reference to CLLocationManager of this
property kCLLocationAccuracyThreeKilometers : a reference to 3000.0
--------------------------------------------------------------------------------
property running : false
property result : missing value -- Lat./long. or error description
property number : 0 -- Error code
property seconds : 10 -- Maximum time to allow script to run
--------------------------------------------------------------------------------
# IMPLEMENTATION:
my performSelectorOnMainThread:"getLocation" withObject:nil waitUntilDone:true
return my result
--------------------------------------------------------------------------------
# HANDLERS & SCRIPT OBJECTS:
to getLocation()
    set locationManager to CLLocationManager's new()

    locationManager's setDelegate:me
    locationManager's setDesiredAccuracy:kCLLocationAccuracyThreeKilometers

    set my running to true
    set started to current date

    locationManager's startUpdatingLocation()

    repeat while my running
        delay 0.5
        if (current date) - started > my seconds then exit repeat
    end repeat
end getLocation

on locationManager:locationManager didUpdateLocations:locations
    local locationManager, locations

    locationManager's stopUpdatingLocation()

    set my running to false
    set my result to (locations's valueForKey:"coordinate") as record
end locationManager:didUpdateLocations:

on locationManager:locationManager didFailWithError:err
    local locationManager, err

    tell err's code()
        set my number to it
        set my result to item (it + 1) in my enum's kCLError
        if it ≠ 0 then set my running to false
    end tell
end locationManager:didFailWithError:

script enum
    property kCLError : {¬
        "Location Unknown", ¬
        "Denied", ¬
        "Network", ¬
        "Heading Failure", ¬
        "Region Monitoring Denied", ¬
        "Region Monitoring Failure", ¬
        "Region Monitoring Setup Delayed", ¬
        "Region Monitoring Response Delayed", ¬
        "Geocode Found No Result", ¬
        "Geocode Found Partial Result", ¬
        "Geocode Canceled", ¬
        "Deferred Failed", ¬
        "Deferred Not Updating Location", ¬
        "Deferred Accuracy Too Low", ¬
        "Deferred Distance Filtered", ¬
        "Deferred Canceled", ¬
        "Ranging Unavailable", ¬
        "Ranging Failure"}
    property CLAuthorizationStatus : {¬
        "Not Determined", ¬
        "Restricted", ¬
        "Denied", ¬
        "Authorized (Always)", ¬
        "Authorized When In Use"}
end script
---------------------------------------------------------------------------❮END❯
EOG

[mliza]

What do you mean by 'removed the quarantine XA from the new version'. when I go to Privacy and Security > Location Services there is nothing related to CoreLocationCLI. The venture settings version is extremely different than the Monterey, have you tried this fix in Ventura?

[JayBrown]

Not yet on Ventura… waiting for .1 update.

Quarantine removal is: xattr -d com.apple.quarantine ./CoreLocationCLI
(The CLI is not signed, so this might be necessary.)

[jtsigros]

The issue for me is that it is not listed in the Privacy & Security -> Location Services section thus you can't disable and re enable.

My mistake is that when I upgraded to Ventura, CorelocationCli didn’t work so I removed it from the list, ever since then I can't get it to register back in.

[jtsigros]

Ive tried running the AppleScript above and the results state "Denied"
Ive also tried using Xcode to compile the source and I still get the following error:

CoreLocationCLI: ❌ Location services are disabled or location access denied. Please visit System Preferences > Security & Privacy > Privacy > Location Services
Program ended with exit code: 1

[JayBrown]

If Apple has removed management of executables from the GUI, which would be typical for these idiots, CoreLocationCLI should still be listed in /var/db/locationd/clients.plist. In my case, I have permissions for versions 3.0.1, 3.1.0, 3.2.0 and 4.0.2 in there. (Not v4.0.1, because I removed it manually in the GUI; see above.) Version 4.0.2 should be under "com.apple.locationd.executable-/usr/local/Caskroom/corelocationcli/4.0.2/CoreLocationCLI" with "Authorized yes". There is also an entry for /usr/local/bin/CoreLocationCLI with a code signature requirement by William Entriken (@fulldecent), so if you've ever had CoreLocationCLI installed in a different path than the Caskroom, whether codesigned or not, it should be listed there as well.

(Don't know why the AppleScript didn't work… have to test it once I'm on Ventura. It's fine on Monterey. On the other hand, there's also an entry for com.apple.osascript in clients.plist… maybe that's necessary to run the AppleScript via osascript.)

[JayBrown]

All this smells like the typical Apple security overkill/overreach. Maybe CoreLocationCLI has to be distributed as a stump app in the future? With the executable CoreLocationCLI placed in ./Contents/MacOS?

[jtsigros]

Ok I got it working via a couple of hacks.
What I did was as follows:

I copied the clients.plist from /var/db/locationd to the desktop
then opened the file in a plist editor (like PlistEdit Pro) and looked for Corelocationcli
I then added the required stuff that were missing:

▶ sudo ls -l /var/db/locationd/
total 304
-rw-r--r-- 1 _locationd _locationd 10512 16 Aug 2018 .dat.nosync0057.DSDdIa
-rw-r--r-- 1 _locationd _locationd 10731 1 Sep 2018 .dat.nosync0058.UKsyve
-rw-r--r-- 1 _locationd _locationd 0 14 Feb 2019 .dat.nosync0059.Dbs87d
-rw-r--r-- 1 _locationd _locationd 0 22 Dec 2018 .dat.nosync0059.kefj2F
-rw-r--r-- 1 _locationd _locationd 11968 18 Feb 2019 .dat.nosync0059.nM3RYY
-rw-r--r-- 1 _locationd _locationd 13874 26 May 2019 .dat.nosync005b.mFDjkN
drwx------ 11 _locationd _locationd 352 15 Jul 2021 Library
-rw-r--r-- 1 _locationd _locationd 51714 24 Nov 13:10 clients.plist
-rw-r--r--@ 1 _locationd _locationd 51714 24 Nov 13:50 clients.plist.bak

make a backup
▶ sudo cp /var/db/locationd/clients.plist /var/db/locationd/clients.plist.bak

copy to desktop
▶ sudo cp /var/db/locationd/clients.plist ~/Desktop/clients.plist

make the desktop copy writable by yourself.
chmod 644 ~/Desktop/clients.plist
ls -l ~/Desktop/clients.plist
-rw-r--r--@ 1 me staff 51714 24 Nov 14:12 /Users/me/Desktop/clients.plist

open desktop copy with a plist editor (eg: PlistEdit Pro)
add a child token and name it Authorized with a value of YES
add a child token and name it Whitelisted with no value

or use BBEdit and add the two fields (Authorized YES) and (Whitelisted):

Save the file

copy the file back to original location overwriting the original
▶ sudo cp ~/Desktop/clients.plist /var/db/locationd/clients.plist

▶ sudo ls -l /var/db/locationd/
Password:
total 304
-rw-r--r-- 1 _locationd _locationd 10512 16 Aug 2018 .dat.nosync0057.DSDdIa
-rw-r--r-- 1 _locationd _locationd 10731 1 Sep 2018 .dat.nosync0058.UKsyve
-rw-r--r-- 1 _locationd _locationd 0 14 Feb 2019 .dat.nosync0059.Dbs87d
-rw-r--r-- 1 _locationd _locationd 0 22 Dec 2018 .dat.nosync0059.kefj2F
-rw-r--r-- 1 _locationd _locationd 11968 18 Feb 2019 .dat.nosync0059.nM3RYY
-rw-r--r-- 1 _locationd _locationd 13874 26 May 2019 .dat.nosync005b.mFDjkN
drwx------ 11 _locationd _locationd 352 15 Jul 2021 Library
-rw-r--r-- 1 _locationd _locationd 46058 24 Nov 14:16 clients.plist
-rw-r--r--@ 1 _locationd _locationd 51714 24 Nov 13:50 clients.plist.bak

make sure permissions, owner and group correct
Reboot your machine

open terminal and try it .....
▶ CoreLocationCLI -f %postalCode
2044

It works !
Still does not show up in the location services in Ventura though.

Be careful with the plist file it can be easily corrupted.
Good luck !

[mliza]

Thanks, @jtsigros that worked!!

[NightMachinery]

This workaround is way too complicated. We need a stump app or a script that modifies (and backups) /var/db/locationd/clients.plist automatically.

[JayBrown]

I've created a script called addloc; see below. I could only test this on Monterey, but it worked on my system.

Needs to be executed as root; input is either the CLI name (if it's in your $PATH), in our case "CoreLocationCLI", or the path to the CLI, in our case either e.g. "/usr/local/bin/CoreLocationCLI" or "/usr/local/Caskroom/corelocationcli/4.0.2/CoreLocationCLI"; dependencies are either the coreutils (for grealpath) or (as fallback) python3; log file created in user library; plist backups are created in /var/db/locationd; before adding, the CLI is dequarantined & ad-hoc-signed, if it has no code signature.

Feel free to edit/improve/report.

https://gist.github.com/JayBrown/c14642a62e424db3cdc933c9140c8de8

[NightMachinery]

I've created a script called addloc; see below. I could only test this on Monterey, but it worked on my system.

Needs to be executed as root; input is either the CLI name (if it's in your $PATH), in our case "CoreLocationCLI", or the path to the CLI, in our case either e.g. "/usr/local/bin/CoreLocationCLI" or "/usr/local/Caskroom/corelocationcli/4.0.2/CoreLocationCLI"; dependencies are either the coreutils (for grealpath) or (as fallback) python3; log file created in user library; plist backups are created in /var/db/locationd; before adding, the CLI is dequarantined & ad-hoc-signed, if it has no code signature.

Feel free to edit/improve/report.

gist.github.com/JayBrown/c14642a62e424db3cdc933c9140c8de8_ (too large to embed)_

Thanks, it worked perfectly. I am now using the following to install the tool.

    brew install --cask corelocationcli &&
        rehash &&
        sudo location_permission_allow_darwin.sh "${commands[CoreLocationCLI]}"

[JayBrown]

Is location_permission_allow_darwin.sh an alternate tool? Or did you just rename it? Because if it's an alternate tool, I'd like to have look. 😉

[NightMachinery]

Is location_permission_allow_darwin.sh an alternate tool? Or did you just rename it? Because if it's an alternate tool, I'd like to have look. 😉

It's a rename. :D

[JayBrown]

OK, thank you. You can btw just input CoreLocationCLI instead of "${commands[CoreLocationCLI]}", because after the rehash the script will find it, because it's running command -v CoreLocationCLI, and then should find the path. (You could also add the rehash to the script at the very beginning to shorten the whole command chain.)

[JayBrown]

I've slightly updated the script: (a) added the rehash command; (b) quarantine XA is only removed if the file is writable; (c) if an executable is already code-signed, the script now extracts the Bundle ID from the signature's Identifier instead of assembling its own ad-hoc ID.

That way it should be possible to also add programs like /usr/bin/osascript to the clients.plist, while using their proper Bundle ID, e.g. to run the AppleScript (above).

But I assume that macOS allows for this anyway, if a program is properly codesigned. (But not sure.)

[chasepeeler]

Tried this and it doesn't let me do anything with clients.plist. I can manually create a copy of it, but that's it. I've tried running it with sudo and running it after sudo su.

[michael-simons]

Holy crap… The amount of work Apple forces on us to use the hardware they way we want is staggering. Thanks a ton for your script, @JayBrown!

@fulldecent It might be worth adding this script to the repo itself and add some instructions.

Also, I want to leave this here for further readers: Even with sudo, Terminal.app doesn't have full disc access by default anymore. You have to enable that in system settings "full disc access" (search for it, I'm on a german machine, sorry), before your can use the script.

[michael-simons]

@chasepeeler you need to enable full disc access for Terminal…

[chasepeeler]

@michael-simons Thanks. That did the trick.

However, CoreLocationCLI is still not showing up in the list for me to enable it

[~]$
sudo ./addloc.sh /opt/homebrew/bin/CoreLocationCLI
*** addloc: Mon Dec 26 22:35:00 EST 2022 ***
INFO: coreutils not detected!
INFO: python3 detected
---
CoreLocationCLI detected
/opt/homebrew/bin/CoreLocationCLI -> /opt/homebrew/Caskroom/corelocationcli/4.0.2/CoreLocationCLI
INFO: removing quarantine extended attribute...
Bundle ID: CoreLocationCLI-55554944304be4d28bac3d2480de892df2a91381
Requirement: cdhash H"40a2c9de62a5470fede346891e3ed22a32c76160" or cdhash H"e994e04de5c32c4597c66cc1a9867c1fcfc646c3"
INFO: adding new client entry...
---
INFO: setting owner & group to '_locationd'
INFO: restarting locationd...
Done.

[JayBrown]

It seems that macOS is not listing CLI programs anymore, no matter what. So the remaining question is whether the new version now works after adding it to the clienst.plist.

[HarrisonWilde]

Sorry to revive this closed issue, but I cannot seem to get this to work even after trying the script provided by @JayBrown , I did get this warning when I ran it:

addloc.sh: line 9: rehash: command not found
*** addloc: Thu 19 Jan 2023 18:10:16 GMT ***
INFO: coreutils not detected!
INFO: python3 detected
---
CoreLocationCLI detected
/opt/homebrew/bin/CoreLocationCLI -> /opt/homebrew/Caskroom/corelocationcli/4.0.2/CoreLocationCLI
INFO: removing quarantine extended attribute...
Bundle ID: com.apple.locationd.executable-/opt/homebrew/Caskroom/corelocationcli/4.0.2/CoreLocationCLI
INFO: code-signing executable with ad-hoc signature...
Requirement: cdhash H"40a2c9de62a5470fede346891e3ed22a32c76160" or cdhash H"e994e04de5c32c4597c66cc1a9867c1fcfc646c3"
INFO: adding new client entry...
---
INFO: setting owner & group to '_locationd'
WARNING: unable to change owner & group!
NOTE: please apply manually if necessary!
INFO: restarting locationd...
Done: 0 of 1 possible errors!

I tried to apply manually but couldn't figure out how:

❯ sudo chown _locationd:_locationd "/var/db/locationd/clients.plist"
chown: /var/db/locationd/clients.plist: Operation not permitted

And after all this, I am still getting the same error as before when I attempt to run CoreLocationCLI. Any ideas on what to try next? Would be keen to find out if you found a way to get lat and long using Applescript too as would probably prefer that if its possible.

[JayBrown]

Maybe you need to add your terminal app (macOS Terminal, iTerm etc.) to the Full Disk Access list in system settings > Security. (Nota bene: I'm still on Monterey.) As for the chown _locationd error, it shouldn't be a problem: the original instructions to manually add a CLI to the clients.plist came without the chown command… I only added that for good measure.

[IoannisTM]

Hello, I also followed the info above and run the script for the clients.plist but it seems to be still popping up the location services message. Not sure what I do wrong . Any ideas on what to look at?

---
CoreLocationCLI detected
/opt/homebrew/bin/CoreLocationCLI -> /opt/homebrew/Caskroom/corelocationcli/4.0.2/CoreLocationCLI
INFO: removing quarantine extended attribute...
Bundle ID: com.apple.locationd.executable-/opt/homebrew/Caskroom/corelocationcli/4.0.2/CoreLocationCLI
INFO: code-signing executable with ad-hoc signature...
Requirement: cdhash H"40a2c9de62a5470fede346891e3ed22a32c76160" or cdhash H"e994e04de5c32c4597c66cc1a9867c1fcfc646c3"
INFO: adding new client entry...
---
INFO: setting owner & group to '_locationd'
INFO: restarting locationd...
Done.
~Downloads CoreLocationCLI
CoreLocationCLI: ❌ Location services are disabled or location access denied. Please visit System Preferences > Security & Privacy > Privacy > Location Services```

[nickkadutskyi]

I got here because I had the same issue on new Mac mini with LocateMe package.
In the end I decided to create a shortcut that gets input text with {LAT} {LON} and replaces those placeholders with actual values based on my current location.
Shortcut has its own way to get access to Location Services so there is no problem with this.

I can use my shortcut in terminal like this:

echo "My Location is: {LAT},{LON}." | shortcuts run "Get Location" -i - | tee

Link to the shortcut https://www.icloud.com/shortcuts/faa5f880cf19481984e9cef20c225a58
I think you can get most of the variables that CoreLocationCLI provides.

[mayurankv]

This similarly didn't work for me when running curl -s https://gist.githubusercontent.com/JayBrown/c14642a62e424db3cdc933c9140c8de8/raw/e874f89915974b90919bd4864891564bf5daedd5/addloc | sudo bash /dev/stdin CoreLocationCLI unfortunately. I'm on Ventura. Has this workaround stopped working?

[roberto2lini]

Running into the same issue as mentioned above by leaf-ts. Is there any other workarounds at the moment for Ventura?

[JayBrown]

I finally upgraded to Ventura, and sure enough, macOS removed all references to CoreLocationCLI, and I wasn't able to update the clients.plist, neither with addloc nor manually.

My current workaround now is a Platypus application using CoreLocationCLI instead of a shell script. This app ("CoreLocationCLI.app") is properly code-signed—only with a Development certificate, which you can get for free in Xcode—, and then the ./Contents/Resources/script is symlinked to /usr/local/bin/CoreLocationCLI, so I can continue to use it in shell scripts or on the command-line… whereas I had to remove the original symlink (from the Homebrew installation) first.

Then CoreLocationCLI will appear in System Settings > Privacy & Security > Location Services.

I assume that when a new update is released, I can just unlink the new CoreLocationCLI in /usr/local/bin, put there by Homebrew, copy the CoreLocationCLI binary from the Cellar directory into the Platypus app, rename it to "script" and replace the old file called "script", then codesign the Platypus app again, and then renew the symlink from the app's Resources to /usr/local/bin.

It's a bit of a hassle, but in principle, @fulldecent could distribute CoreLocationCLI as an app bundle to begin with, and symlink its executable into /usr/local/bin. Should probably work.

[JayBrown]

Here's the app: CoreLocationCLI.app.zip

Download, remove the quarantine XA from the app or the archive (because it's not notarized), drop (for example) into /usr/local/Caskroom/corelocationcli/app/, launch the fake app once to register it with macOS, go to System Settings > Privacy & Security > Location Services, enable the app CoreLocationCLI in the list, then symlink with

ln -s /usr/local/Caskroom/corelocationcli/app/CoreLocationCLI.app/Contents/Resources/script /usr/local/bin/CoreLocationCLI

and type y to replace the Homebrew symbolic link.

This could be the default way to distribute CoreLocationCLI via Homebrew Cask in the future.

Nota bene: an update of CoreLocationCLI, installed with Homebrew, will probably delete the directory /usr/local/Caskroom/corelocationcli/4.0.2 and all its contents, so it's probably best to put the app somewhere safe, where there's no risk of it getting deleted.

[delize]

I have been trying to run through this at the moment using your platypus app and addloc script, but this does not appear to be working...

user@user Downloads % sudo c14642a62e424db3cdc933c9140c8de8-e874f89915974b90919bd4864891564bf5daedd5/addloc CoreLocationCLI
*** addloc: Thu Aug 10 19:41:03 CEST 2023 ***
INFO: coreutils detected
---
CoreLocationCLI detected
/usr/local/bin/CoreLocationCLI -> /usr/local/Caskroom/corelocationcli/app/CoreLocationCLI.app/Contents/Resources/script
INFO: removing quarantine extended attribute...
Bundle ID: script
Requirement: identifier script and certificate root = H"8954f3532556fc46270b708d03c4a9e8767d85df"
INFO: adding new client entry...
---
INFO: setting owner & group to '_locationd'
INFO: restarting locationd...
Done.
user@user Downloads % CoreLocationCLI
user@user Downloads % cd ~
user@user ~ % CoreLocationCLI
CoreLocationCLI: ❌ Location services are disabled or location access denied. Please visit System Preferences > Security & Privacy > Privacy > Location Services
user@user ~ %

Can anyone confirm this is working on 13.5? Location Services are definitely enabled:

[jtsigros]

I couldn’t get the script to work, but the manual way of adding the keys in the plist file still works. I have it running using that method and works...

▶ CoreLocationCLI
-33.919854 151.177872

On a side note, it looks like it Sonoma (14.0 beta5) it looks like you can select it in the privacy & security/developer tools section

[GITbaburin]

Whore those who are on Sonoma. Add Authorized with boolean type = true into the plist file. those guys at apple, waaa!