Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better MCX description and support with new pfm_ keys #399

Open
ygini opened this issue Dec 31, 2020 · 0 comments
Open

Better MCX description and support with new pfm_ keys #399

ygini opened this issue Dec 31, 2020 · 0 comments

Comments

@ygini
Copy link

ygini commented Dec 31, 2020

Preference Manifest is a old file format, originally used to describe actual Preferences (as stored in NSUsersDefault) for an app.

This description was then used in Workgroup Manager to generate a dynamic tableview based UI to help IT people to manage app preferences.

Managed preferences was able to be set using one of those 3 behaviors:

  • ONCE, the initial preference in NSUserDefaults, with capabilities for the user to change it
  • OFTEN, the preferences in NSUserDefaults reset at each login time, user was able to change it when using the app but at next login, everything was back to the IT choice
  • ALWAYS, the preferences was forced in NSUserDefaults and the app has to be specifically written to check for the managed state and so disable preferences changes in its own settings

Something important to keep in mind, MCX has never disappeared and are still supported and used. MCX distribution via LDAP is gone. And now MCX are distributed via a configuration profile using the following payload format:

https://developer.apple.com/documentation/devicemanagement/managedpreferences

With this move from MCX over LDAP to MCX over Profile, we are now restricted to two behaviors, Forced and Set-Once.

Here, on this repository, we use pfm file format to represent a Profile, which is not the same things, and so pfm standard initially described by Apple have evolved to match the new needs.

That's great but that does not allow the pfm reader to know what we are reading now.

Are we reading an actual MCX or a modern Profile? There is no key to give us a clue on that.

This is why I request the introduction of two new keys.

The first one is pfm_manifest_type as a mandatory fixed string value with the following state:

  • mcx, this is MCX preference that will need to be wrapped in a MCX Profile Payload, the pfm does not describe the wrapper itself, it simply request it
  • profile, this is a Profile payload that will be directly usable in a Profile envelope
  • not set, this manifest hasn't been reviewed recently and should be considered carefully

This let us room for extension in the future.

The second one is pfm_mcx_behavior as a mandatory fixed string when pfm_manifest_type is set to mcx, with the following state:

  • once, the described preferences and app support the set once behavior
  • forced, the described preferences and app support the forced behavior

When not set, once should be assumed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant