Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use managed preferences in 10.6 to restrict user accounts, including allowed applications, to allowed folders. This works by allowing the *.app folder for individual applications or other folders containing scripts, for example. I do this by folder to avoid having to re-allow apps because of new application signatures when updating certain applications, and for scripts.

Under 10.6, child applications and processes invoked by the allowed applications are allowed. Under 10.7, no child processes are being allowed. This extends even to user-level system services started by the loginwindow process (such as pboard [system pasteboard] and distnoted [distributed notification system]). Thus, when I apply "by folder" application whitelisting to a user in 10.7, it essentially breaks the usability of that account for any purpose.

Perhaps a better example would be Terminal. If I allow Terminal, /usr/bin/login is disallowed, making Terminal useless. If I allow /usr/bin/, then ls, mv, and cp are still disallowed because they are contained in /bin/.

It seems quite impossible to whitelist every possible helper application and unix executable that may be called by an allowed application. This behavior persists under 10.7.1, on fresh installs, with newly created users.

I use dscl (via an installer) to import managed preferences for the user from a plist generated by mcxexport. Is there a key I can add to the managed preferences which would allow child processes for whitelisted (by folder) applications? I cannot find a setting in Workgroup Manager to allow child processes. Has anyone else experienced this problem?

share|improve this question

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.