iCloud Desktop and Documents in macOS Sierra – The Good, The Bad and the Ugly
As part of the iCloud services in macOS Sierra, Apple is offering a new way to store your files in iCloud – synchronizing the contents of your account’s Desktop and Documents folder with iCloud Drive.
When you enable the option to store files from your Desktop and Documents folder, the contents of your Desktop and Documents folder are moved (not copied) from your home folder into iCloud Drive. Those folders will no longer appear in your home folder.
That means that your Desktop and Documents folder no longer are stored in your home folder. Instead, they and all their contents are now stored in iCloud Drive.
For more details on this, see below the jump.
fdesetup authrestart no longer requires an immediate restart in macOS Sierra
Apple made a change to the fdesetup authrestart command in macOS Sierra, where running fdesetup authrestart will no longer require the encrypted Mac in question to restart immediately.
The delayed restart option can be enabled by adding the -delayminutes verb to the fdesetup authrestart command and specifying one of the following:
- Time in minutes = Delay the restart command for a set number of minutes
- 0 = immediate restart
- -1 = wait indefinitely for restart
Using the -1 option means that the user can restart at their convenience and their encrypted Mac will automatically bypass the FileVault 2 pre-boot login at the next reboot.
To show what this behavior looks like, please see the videos below:
fdesetup authrestart delayminutes 0
fdesetup authrestart delayminutes 0
Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 30 seconds.
fdesetup authrestart delayminutes 1
fdesetup authrestart delayminutes 1
Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 2 minutes 18 seconds.
fdesetup authrestart delayminutes -1
fdesetup authrestart delayminutes -1
Note: The video has been edited to artificially reduce the amount of time the restart process takes to run. Run time of the pre-edited video was 1 minute 43 seconds.
tty_tickets option now on by default for macOS Sierra’s sudo tool
While working on some documentation, I noticed a behavioral change in macOS Sierra’s sudo tool that was different from how sudo behaves on OS X El Capitan.
El Capitan
if you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you won’t be prompted for your password in either Terminal session until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:
Sierra
If you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you’ll get asked for your password in the second Terminal session too. Meanwhile, in the first Terminal session, you won’t get prompted again until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:
The difference is that Apple has compiled sudo on Sierra to include the tty_tickets option, which ensures that users need to authenticate on a per-Terminal session basis.
This option had not been included in sudo on OS X El Capitan and earlier, which had been viewed as a privilege escalation vulnerability.
If you want sudo to return to using the pre-Sierra behavior on macOS Sierra, edit /etc/sudoers to add the following option:
macOS Sierra’s /Volumes folder is no longer world-writable
One of the changes made in macOS Sierra is summed up by my colleague @n8felton below:
/Volumes is the invisible directory used by OS X and macOS as the OS’s default mount point for accessing the filesystems of other storage (like external hard drives, USB flash drives, mounted disk images, network fileshares, etc.)
Up to OS X El Capitan, the /Volumes directory was world-writable and had the following permissions:
This meant that any process or user could create a directory inside /Volumes or store files there.
World-writable directories are generally seen as a security risk, which may explain why Apple chose to change the permissions on the /Volumes directory. As of macOS Sierra, the permissions on the directory are as follows:
This change means that the /Volumes directory is readable by anyone but can only be written to by processes using root privileges.
This permissions change should not affect the system’s ability to mount storage devices or fileshares from network servers, as the OS itself is the one handling the mounting and has all the necessary permissions.
Blocking Siri on macOS Sierra
Siri is a welcome addition to macOS Sierra, but in certain environments it’s a service which needs to be disabled. For those Mac admins who need to do this, here are the relevant keys:
Stop Siri from running:
Block Siri’s menubar icon:
For those who want to disable Siri using management profiles, I’ve created .mobileconfig files and posted them here on Github:
https://github.com/rtrouton/profiles/tree/master/DisableSiri
Hat tip to Brad Vrooman for posting about the correct settings.
Suppressing Siri pop-up windows on macOS Sierra
Starting in 10.7.2, Apple set the iCloud sign-in to pop up on the first login.
In 10.10, Apple added a new Diagnostics & Usage window that pops up at first login after the iCloud sign-in.
In 10.12, Apple added another new pop-up window for Siri.
To stop the Siri pop-up window from appearing for your home folder, run the command shown below:
defaults write com.apple.SetupAssistant DidSeeSiriSetup -bool TRUE
Since you normally will be able to run this command only after you’ve seen the Siri pop-up window, I’ve updated my script for suppressing the iCloud and Diagnostic pop-up windows to now also suppress the Siri pop-up window. For more details, see below the jump.
Building a Casper smart group containing Sierra-incompatible Macs
As part of preparing for macOS Sierra, I’m planning to provide a way for my customers to upgrade themselves to Sierra via Casper’s Self Service. Unlike the upgrade process I was able to provide for OS X Yosemite and El Capitan, where I could filter based on whether or not a particular Mac could run OS X 10.8.x, Sierra’s system requirements exclude some Macs which can support running OS X El Capitan.
To help make sure that Self Service wasn’t providing the option of upgrading to macOS Sierra to a Mac which couldn’t run it, I needed to compile lists of which Mac models could and couldn’t run macOS Sierra, based on the system requirements that Apple provided. For more details, see below the jump:
Recent Comments