Search code examples
macososx-mountain-lionautomator

Programmatically modifying parental controls on Mac OS X


Mac OS has a very basic set of parental control options that allow you to limit user's access to websites and apps, as well a set daily time limits. I want to be able to script this to do something like the following:

Allow access from 8am to 9:30 am for specific sites, restrict access to games. Allow general access from 5pm to 6:00 pm.

I'm not sure where to start in terms of scripting this on Mac OS 10.8. Any suggestions? Is this something Automator can handle or am I better off using a cron job/shell script?


Solution

  • The Parental Controls are enforced using the regular ol' Managed Preference (aka MCX) frameworks that have been around since 10.2. It stores them in the local directory services in the mcx_attributes attribute for the user in question.

    To set them, or any managed setting, outside of the GUI all you need to do is feed in a properly formatted plist using the mcx plugin of the dscl tool into the user. Using local directory service policy like this is well understood and documented by the OS X sysadmin community.

    The easiest way to get started with understanding this is to setup some Parental Controls, then inspect the mcx attributes using the Directory Utility app from /System/Library/CoreServices or the dscl command which will let you explore your directory services as if it were a file system with cd and ls.

    Once you see what the keys are that get set in the XML you can start crafting your own. You can also use the dscl . -mcxexport command. This will dump the management configuration out and you can then import it later. Check out dscl . -mcxhelp for the lowdown on the mcx plugin.

    To review the process of implementing this with a script is:

    1. Create a xml plist that contains the policy information you want.
    2. Import that plist onto the proper account with dscl . mcximport

    A more forward looking alternative would be to create a Configuration Profile (Which is just a plist file as well.) and then load it with the profiles command. If you take the configuration profile route then there isn't any messing about in directory services or the dscl command to worry about.