Remove Applications from Location Services in Security & Privacy on Mac OS X 10.8
Solution 1
Xcode's property list editor can also be used to delete old apps' entries, but since the file is hard to get to, permissions have to be temporarily opened:
mini-nevie:~ root# chmod o+rwx /var/db/locationd/ /var/db/locationd/clients.plist
so the directory and file can be read and written by all users. Then, for convenience, su to your login ID:
mini-nevie:~ root# su - nevinwilliams
mini-nevie:~ nevinwilliams$ open /var/db/locationd/clients.plist
This assumes Xcode is the default app for opening *.plist files, and you're familiar with the Property List Editor. Under the Root property, there are 3 default Dictionary entries:
com.appl
com.appl.locationd.executable-/usr/libexec/UserEventAgent
com.appl.aosnotifyd
Those ought not to be removed. For entries that belong to long-gone apps, you can hover just to the left of the Dictionary column of the corresponding app's row, where an inverse grey '-' will appear. Clicking on it will remove the item, and all its children. If you'd rather inspect the entry first, clicking on the grey triangle (familiar to Finder list-view users) to the left of the key string will expand the Dictionary and display its elements.
Once you delete or disable the keys to your satisfaction, save the file, and quit Xcode. Then, back in Terminal, do:
mini-nevie:~ nevinwilliams$ exit
logout
mini-nevie:~ root#
hit the up-arrow twice to recall the chmod command, ctrl-A to go to the beginning of the line, cursor-right about eight times, change the '+' to a '-', or enter the following as shown to restore permissions to what they were:
mini-nevie:~ root# chmod o-rwx /var/db/locationd /var/db/locationd/clients.plist
then HUP the location daemon:
mini-nevie:~ root# killall -HUP locationd
a quick check of the Security.PrefPane Privacy tab ought to confirm your changes.
Standard disclaimers, cautionary tales of woe, scoldings, cluckings, and "Is This Trip Really Necessary?" reflections are especially applicable.
Solution 2
Using tccutil (OS X Command Line utility)
I think the fastest and safest way to do this, is by the OS X command line utility tccutil
- Open a new terminal window
- Close any open "Security & Privacy" prefpane windows
- Type or paste from the following highlighted commands
Reset the Location services
tccutil reset CoreLocationAgent
Reset access to contacts/address book:
tccutil reset AddressBook
Reset access to Reminders
tccutil reset Reminders
Reset access to Calendars
tccutil reset Calendar
And that´s all there is to it. No Sudo needed, by the way.
Solution 3
This is the old one and the solution I propose isn't technically different from the solution in the post and accepted one, but it's much less hassle and much easier to automate (useful for debugging). Just do
/usr/libexec/PlistBuddy -c 'Delete <bundle-id>' /var/db/locationd/clients.plist
killall -HUP locationd
as root.
Related videos on Youtube
Scot S
Updated on September 18, 2022Comments
-
Scot S almost 2 years
I wanted to remove applications from location services in the security and privacy settings on MaC OS X 10.8 Mountain Lion. (The apps were still listed even though they were uninstalled.) I found the post Remove application from Location Services in Security & Privacy on Mac OS X 10.7, and that got me going in the right direction. Here is the OS X 10.8.2 Mountain Lion equivalent that worked for me. The main difference is the location of the clients.plist file. I also wanted to provide a step-by-step process.
DISCLAIMER: This worked for me. Make sure you have a good backup of your system. This process includes making a backup of the clients.plist file, but one can never be too safe.
1. Start terminal and then sudo to a root shell
sudo -s
2. Go to /var/db/locationd
cd /var/db/locationd
3. Make a backup of the clients.plist file
cp -p clients.plist clients.plist.save
4. Convert clients.plist to xml (editable format)
plutil -convert xml1 clients.plist
5. Use vi (vim) to edit the clients.plist file and remove the application.
vi clients.plist
The file will likely contain many application entries. Here is the format of a single application entry (Safari in this case). The entire entry needs to be deleted.
<key>com.apple.Safari</key> <dict> <key>Authorized</key> <true/> <key>BundleId</key> <string>com.apple.Safari</string> <key>Executable</key> <string>/Applications/Safari.app/Contents/MacOS/Safari</string> <key>LocationTimeStopped</key> <real>376348187.80421197</real> <key>Registered</key> <string>/Applications/Safari.app/Contents/MacOS/Safari</string> <key>RequirementString</key> <string>identifier "com.apple.Safari" and anchor apple</string> <key>Whitelisted</key> <false/> </dict>
6. Convert the clients.plist file back to binary
plutil -convert binary1 clients.plist
7. Restart locationd
killall locationd
If the apps are still there, do the process again, except restart locationd using kill -9 after determining the PID as follows. The PID is the second field in the ps output.
ps -ef | grep locationd | grep -v grep
Output:205 427 1 0 6:31PM ?? 0:00.07 /usr/libexec/locationd
kill -9 427
I ran the process twice to remove one app at a time. The first time, killall was sufficient. The second time, it was not. I do not know why. It acted like locationd was keeping a cache and rebuilding clients.plist. I say this because the entries were added back to clients.plist after running killall -- and even on a reboot. Whatever the root cause, using kill -9 solved the problem for me.
If things go badly, then copy back the original file and restart locationd.
cp -p clients.plist.save clients.plist
killall locationd
(or the kill -9 method)I hope this helps. Cheers!
-
Nevin Williams about 11 yearskill -HUP might be more reliable; it's the legacy kill signal to tell a daemon to flush its cache and re-read its config file. I see that killall -HUP locationd would work. A possible reason the other kills didn't work might be the cache files were left to be read by the newly spawned process.
-
DonielF over 6 yearsFun fact: I'm not sure whether this behavior existed before High Sierra, but at least in this macOS if you uncheck a file that no longer exists in the preferences pane, usually the app will no longer display it in the list. However, using this method, I discovered that several of these supposedly deleted apps were, in fact, still in the list, just not displayed.
-
DonielF over 6 yearsI should also note, based on my experience with this: I tried using this to remove an Applescript of mine from System Preferences, for reasons, and it kept popping up that it wanted my location for several attempts until it finally shut up. I assume this is because I kept trying to run that line of code in the Applescript, and the bash kept running in the background until it was deleted from my System Preferences...and thus it went on to the next line in the bash. Since I had multiple of these running in the background, apparently, I had to cancel each one individually while doing this.
-
-
strangetimes over 6 yearsNot working for me unfortunately. I get a Failed to reset database message.
-
Andreas over 6 years@strangetimes: I had totally forgotten about this. I have not tried the modified tccutil mentioned in this link, but it seems to me like it's worth a shot: github.com/jacobsalmela/tccutil
-
Andreas over 6 years@strangetimes : I forgot to mention that the reason it's not working, is due to the system integrity protection, according to github.com/jacobsalmela/tccutil
-
Jadim over 5 yearsThe command
tccutil reset CoreLocationAgent
does not seem to work anymore. See this issue. -
Cristi Băluță over 5 yearsIt worked for me to remove the calendars but is not working to request a new authorization. To do that i had to remove the user/library/calendar/calendar cache database then restart the computer
-
dbv over 4 yearsWorks for me. Thanks!
-
Nickolay Olshevsky over 3 yearsDidn't work for me on macOS 10.15.7 - while PlistBuddy doesn't report an error, the record is still there. And now things are even more funny - while item is not displayed in the GUI, it is still in the plist.
-
Eddie Curtis over 3 years@NickolayOlshevsky, indeed, doesn't seem to work anymore. Interestingly, after running the command, timestamp of the plist is not updated. And
touch
reports "Operation not permitted". I think it has to do with the new macos system integrity protection thingie or some other newer security feature… -
Nickolay Olshevsky over 3 yearsLooks like a root is not a real root anymore.
-
Eddie Curtis over 3 years@NickolayOlshevsky, yes, not what it used to be… There's still an option to turn integrity protection off, I believe, but I wouldn't bother.