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.
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:
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:
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.
In the course of my testing of macOS Sierra this week, I decided to turn on iCloud Desktop and Documents syncing. This was my reaction:
I can’t discuss the details of my testing yet because the macOS Sierra NDA still applies until Sierra is released on September 20, 2016. However, for those Mac admins who have also tested this and wish to block it in their own environments ahead of macOS Sierra’s release, I’ve built a management profile and made it available via the link below:
This profile has been tested and works on OS X 10.11.6 and later. It restricts access to the iCloud Drive settings in the iCloud preference pane by graying out iCloud Drive and making it non-selectable.
As part of Apple’s Upgrade to macOS Sierra documentation, there’s been a change in the system requirements for macOS Sierra as opposed to OS X El Capitan.
For OS X El Capitan, the earliest OS you can upgrade from is Mac OS X Snow Leopard 10.6.8.
For macOS Sierra, the earliest OS you can upgrade from is OS X Lion 10.7.5.
If you’re upgrading from 10.6.8, Apple’s guidance is to upgrade first to El Capitan and then to Sierra.
As part of the pre-release announcements about macOS Sierra, Apple released the following KBase article:
As part of the KBase article, Apple included a Changes coming with macOS Sierra section which featured this note:
Portable home directories (PHDs) were Apple’s attempt at providing roaming user profiles. Starting in Mac OS X 10.3.x, you could configure a person’s account so that the data in their home folder resided on a server in a network home folder. The data on the server was then synchronized with copies of the same data residing on the one or more Macs that particular person used on a day-to-day basis.
It was also possible to configure what data was synchronized between the Mac(s) and the server, to conserve space on the server for only essential data.
Unfortunately, the idea was better in concept than it was in execution. Depending on how much data needed to be synchronized, the copying process between the server and the individual Macs could take a while.
Synchronization conflicts were also left for the user to figure out, which usually meant a call to the local help desk.
The synchronization agent itself was prone to crashing when working particularly hard.
The problems with the synchronization process, coupled with the increasing availability of continuous backup solutions like CrashPlan and Apple’s diminishing support for PHDs, helped make portable home directory deployment something many Mac admins avoided. Nine OS releases after PHDs’ initial debut in 10.3.x., it appears Apple now agrees with that sentiment.
Unplug USB and Thunderbolt devices when setting up Windows 8.x or 10.x using Boot Camp on OS X El Capitan
As part of setting up a dual-boot configuration for a group at my shop, I was working with a colleague to set up a new Windows 10 installation using Boot Camp on a new Retina MacBook Pro. As part of the process, we did what we normally did and plugged in a USB flash drive to store the Windows installation files on.
The Boot Camp Assistant asked for the location of the Windows 10 .iso file, proceeded to repartition the disk, then rebooted into the Windows install process. When prompted where we wanted to install Windows, we selected the BOOTCAMP partition and clicked Format.
At that point, Windows formatted the drive. So far so good. We then selected the drive, clicked the Next button, and received the following error:
We couldn‘t create a new partition or locate an existing one. For more information, see the Setup log files.
Our thought at that point was that something had gone wrong with the format, so we booted back to OS X, had Boot Camp Assistant remove the Windows partition and tried again.
Same result, same error.
We went back to the Boot Camp documentation and read it over carefully. There is a note about unplugging Thunderbolt devices, but we didn’t have any plugged in.
So we tried again, starting over from scratch. Same result, same error.
After some additional research, we finally found the answer: The note should have read “Thunderbolt or USB storage devices”. This additional information is included in an Apple KBase article for installing Windows 8 using Boot Camp, which has the following procedure:
- Shut down your computer.
- Disconnect all Thunderbolt and USB storage devices, except for the USB media which contains the Windows ISO installer.
- Try the installation again.
But the reason we had any USB drives plugged in was because we had thought Boot Camp Assistant was going to store the Windows installer on that flash drive. So why was Windows complaining?
The answer is Boot Camp in El Capitan does not store the Windows ISO installer on a USB flash drive. Instead, the Boot Camp Assistant will create a temporary FAT32 partition, name it OSXRESERVED, and store the Windows installation files on the OSXRESERVED partition.
Since the USB flash drive wasn’t being used as the source of Windows installer files, having it plugged in was causing the error to appear.
So we shut down, unplugged the USB flash drive, and again re-ran the installation. This time, no error and Windows 10 installed without a problem.
As part of the release of Casper 9.93, JAMF has added options for suppressing the iCloud and Diagnostics pop-up windows to the following MDM profile payloads:
- Login Window
- Security & Privacy
The iCloud pop-up window can be managed via the Login Window profile payload. To suppress the iCloud pop-up window, click on the Options tab for that payload and check the Disable Apple ID setup during login option.
The Diagnostics pop-up window can be managed via the Security & Privacy profile payload. To suppress the Diagnostics pop-up window, click on the Privacy tab for that payload and uncheck the Allow sending diagnostic and usage data to Apple, and sharing crash data and statistics with app developers option.