hoakley July 19, 2018 Macs, Technology

Updated tools for checking and correcting Home folder permissions

Having established that macOS still supports repairing the permissions of your Home folder, and that this is still a solution supported by Apple, it is time to update the two tools which are available here to help you do that.

PermissionScanner 1.2 is a general-purpose tool for checking permissions in the following locations:

~/Library/Preferences
~/Library/Preferences and individual preferences files in ~/Library/Containers and ~/Library more generally
~/Library as a whole
the whole of your Home folder
/Library/Preferences

In each folder, you can look for those files for which you don’t have read and write access, or read access. This allows you to correct any stray permissions manually when needed to fix problems.

Version 1.2 now runs scans in the background, which spares you from seeing the spinning beachball during longer scans. It is also fully compatible with macOS Sierra, High Sierra (including APFS), and with Mojave, including Dark Mode. It’s available from here: permscan12
and from Downloads above.

RepairHomePermissions 1.0 is the first full release of a tool to step through Apple’s recommended process for repairing permissions on your Home folder.

It starts by showing you how to set and propagate correct permissions in your Home folder. Once you have done that, click on the Repair Permissions button. This automatically works through the sequence of commands recommended by Apple to complete repairing permissions, saving you from having to use Terminal.

This version has been largely rewritten, so that it runs command tasks in the background rather than show the spinning beachball, and is fully compatible with Sierra, High Sierra (including APFS), and now Mojave (including Dark Mode). It’s a single window app, which conveniently quits when you close its window. It’s available from here: rhpb1rel
and from Downloads above.

4Comments

Add yours

1

Marcel on October 11, 2018 at 10:25 am

Hi, these are some nice tools, thank you for your work. But I think it’s also important to keep some special behaviour in mind:

If you propagate the permissions like Apple is recommending, you will give the group ‘staff’ and ‘everyone’ readable access to every folder, which is not part of the standard home folder in macOS!

A good example is the Dropbox folder, which will be added normally inside ~ of your home folder, also Calibre likes to add it’s Library there, and a lot of other 3rd party tools do that too (think of Microsoft OneDrive, Adobe CC files and so on).

Unfortunately ‘diskutil resetUserPermissions’ will only change the privileges of standard folders like Desktop, Documents and so on (as far as I know) – but extra folders like e.g. the Dropbox folder stays readable for ‘staff’ and ‘everybody’, which is really bad I think …

In managed enviroments we handle it like this (as a maintainance policy available inside the ‘Self Service’ app of our jamf PRO server):

#!/bin/bash

consoleUsername=$(stat -f %Su /dev/console)
consoleUserID=$(stat -f %u /dev/console)

sudo chown -R $consoleUserID:20 /Users/$consoleUsername/*
sudo chmod -R 700 /Users/$consoleUsername/*

sudo -u “$consoleUsername” chflags -R nouchg ~
sudo -u “$consoleUsername” diskutil resetUserPermissions / $consoleUserID

exit 0

This way all the special folders stay unreadable for ‘staff’ and ‘everyone’. But this might be problematic for others, don’t know (for example, if they need the ~/Public/Drop Box folder or the old ~/Sites folder).

I do remember there is also a special security command to force a different behaviour for all macOS home folders, this way newly added folders inside ~ will always be forbidden for ‘staff’ and ‘everyone’.

But right now I can’t find the exact command, sorry. Will add it, if I’ve found it.

Also, ACLs could handle that behaviour, but I think the security command is the better way.

LikeLiked by 1 person
- 2
  
  hoakley on October 11, 2018 at 11:01 pm
  
  Thank you, Marcel.
  I don’t think that Apple has ever documented what diskutil resetUserPermissions actually does, beyond that Support Note. Outside a managed environment, I would be loathe to advise ordinary users to try to run shell scripts which they don’t understand, and which conflict with Apple’s instructions.
  The old repair permissions used installer BoMs to work out what permissions should be. Perhaps it would make better sense to be able to create a ‘master’ list of Home folder permissions, and to reset them to that, but I don’t know of any tool which does that.
  Howard.
  
  LikeLike
3

Marcel on October 11, 2018 at 10:01 pm

Ok, found the ‘trick’ now … it wasn’t a part of the security command, but with the help of the umask command. 🙂

Normally every user in macOS has 022 as the standard umask setting, which gives newly created folders inside the users home folder the read access for staff and everyone.

If you wanna change that standard behaviour, you have to change it to 077, which you can do with the following command:

sudo launchctl config user umask 077

Be aware a restart is required after that.

This way every newly created folder inside the users home folder gets only read and write for the user itself and no access for staff and everyone. Wondering why this is not the standard behaviour for macOS?

So the script looks slightly different now (added also an option to remove all ACLs with the -N option of chmod and activated the verbose mode for better log check ability):

#!/bin/bash

consoleUsername=$(stat -f %Su /dev/console)
consoleUserID=$(stat -f %u /dev/console)

sudo chown -R -v $consoleUserID:20 /Users/$consoleUsername
sudo chmod -R -v -N /Users/$consoleUsername
sudo chmod -R -v 700 /Users/$consoleUsername

sudo -u “$consoleUsername” chflags -R nouchg ~
sudo -u “$consoleUsername” diskutil resetUserPermissions / $consoleUserID

sudo launchctl config user umask 077

exit 0

LikeLike
- 4
  
  hoakley on October 11, 2018 at 11:05 pm
  
  Thank you.
  One reason for Apple using that umask is for folders like Public. Outside of managed environments, read access for staff and everyone are seldom an issue at all, and with Mojave’s privacy controls, largely irrelevant, I think.
  I would advise ordinary users to avoid ACLs altogether, as they can get into quite a pickle if they don’t understand them: they’re powerful tools for knowledgeable sysadmins, but most users find them very confusing, if they have heard of them at all.
  Howard.
  
  LikeLike

·Comments are closed.

Share this:

Related