Skip to main content

I apologise to my fellow Mac experts for stating what to them will be obvious but do so for the benefit of other readers.

Mac apps (mostly) use XML format preference files signified by a file extension of .plist

These preference files can be in one of three locations.

1. ~/Library/Preferences - that is in the Preferences folder in the Library folder in the users home directory
2. /Library/Preferences
3. /Library/Managed Preferences

(I am deliberately ignoring the ByHost folders.)

In theory it does not make any difference which location is used, it is also possible to have the same plist file in more than one location and have some keys in one copy and some keys in the other and the macOS will effectively merge the two although if a key is in both obviously only one version will have an effect.

This works for me for the case of a preference file in ~/Library/Preferences and /Library/Preferences

However if I have the same preference file pushed out via - in my case Jamf Pro so that it ends up in /Library/Managed Preferences and also have the same preference file in ~/Library/Preferences then this does not work. In this case it seems to only read the Jamf Pro version even though there is no conflicting keys and yes the same preference file name is used.

The reason I want to do this is I plan to store a 'security key' in a preference file in -

/private/var/root/Library/Preferences

but to push all other settings for the app out via Jamf Pro. This is because otherwise it is possible for even an ordinary level user to view the content of the Jamf Pro version including of course the security key. As the above location is not accessible to standard level users and not in the Finder to even Admin level users.

Can anyone comment on whether this is 'expected behaviour' or a bug or whether I am 'holding it wrong' 😀

@jelockwood You don't want to be putting .plist files directly into /Library/Managed Preferences yourself as that's where settings deployed via a Configuration Profile end up and settings there should override the same setting in any other location. Other settings for the same preferences domain in ~/Library/Preferences and /Library/Preferences should work if they're different keys, so not sure why you're seeing the behavior you describe with no settings working from those locations. Note that some applications do not properly support preferences set via Configuration Profile (GlobalProtect VPN was guilty of this in older versions, I don't know if it has improved)

Is this 'security key' you're trying to deploy for a 3rd party product, or something you're developing for your own org? If the latter I'd strongly recommend you look at using the macOS Keychain APIs to store/access it rather than trying to hide a .plist containing it (and if it's the former tell the 3rd party's developers to do the same).

@jelockwood You don't want to be putting .plist files directly into /Library/Managed Preferences yourself as that's where settings deployed via a Configuration Profile end up and settings there should override the same setting in any other location. Other settings for the same preferences domain in ~/Library/Preferences and /Library/Preferences should work if they're different keys, so not sure why you're seeing the behavior you describe with no settings working from those locations. Note that some applications do not properly support preferences set via Configuration Profile (GlobalProtect VPN was guilty of this in older versions, I don't know if it has improved)

Is this 'security key' you're trying to deploy for a 3rd party product, or something you're developing for your own org? If the latter I'd strongly recommend you look at using the macOS Keychain APIs to store/access it rather than trying to hide a .plist containing it (and if it's the former tell the 3rd party's developers to do the same).


@sdagley I am not putting the .plist myself in to /Library/Managed Preferences, this is being done by Jamf Pro as a profile using the same app domain name as the 'hidden' one in /private/var/root/Library/Preferences

Unfortunately it is a 3rd party app so whilst I have used the keychain approach before - and in a similar scenario would use the System keychain but cannot in this case. The app in question does support using a configuration profile it just is not combining keys from both locations.

@sdagley I am not putting the .plist myself in to /Library/Managed Preferences, this is being done by Jamf Pro as a profile using the same app domain name as the 'hidden' one in /private/var/root/Library/Preferences

Unfortunately it is a 3rd party app so whilst I have used the keychain approach before - and in a similar scenario would use the System keychain but cannot in this case. The app in question does support using a configuration profile it just is not combining keys from both locations.


@jelockwood You've piqued my interest, and I'm guessing you don't want to say much publicly, so I've sent you a Private Message

Reply


Terms & ConditionsCookie settings